加入收藏 | 设为首页 | 会员中心 | 我要投稿 站长网 (https://www.0550zz.com/)- 智能边缘云、设备管理、微服务引擎、研发安全、云防火墙!
当前位置: 首页 > 服务器 > 搭建环境 > Unix > 正文

Linux老手也常踩的5个Unix环境搭建坑

发布时间:2026-10-12 10:32:43 所属栏目:Unix 来源:DaWei
导读:  去年八月份那场Unix环境迁移,我现在想起来还火大——告警响了三次,全是“locale not found”,可那几台机器的locale明明是我亲手编译的!开发在群里喊“服务挂了”,我盯着屏幕上的“LC_ALL=en_US.UTF-8”直犯懵——明明

  去年八月份那场Unix环境迁移,我现在想起来还火大——告警响了三次,全是“locale not found”,可那几台机器的locale明明是我亲手编译的!开发在群里喊“服务挂了”,我盯着屏幕上的“LC_ALL=en_US.UTF-8”直犯懵——明明配置文件里写的是C.UTF-8,怎么进程里全变了?后来才发现,/etc/default/locale里的变量被某个脚本覆盖了,可那脚本是三年前写的,早没人记得它存在。

  第一个坑是“默认配置的优先级”。我原以为/etc/environment里的变量优先级最高,结果发现某些旧版Unix(比如Solaris 10)的PAM模块会先读/etc/profile,再读/etc/environment,最后还可能被用户目录下的.pam_environment覆盖。那天我改完/etc/environment,重启服务后发现LANG还是乱码,最后在/home/xxx/.pam_environment里找到了“LANG=zh_CN.GBK”——这文件是五年前某个离职同事留的,连注释都没有,谁他妈记得去删它?

  第二个坑更离谱——时区文件。好几台机器的/etc/localtime是硬链接到/usr/share/zoneinfo/Asia/Shanghai的,我按惯例用“ln -sf”重新链接,结果服务启动后日志时间差了八小时。开发在群里骂“日志时间对不上怎么排查问题”,我查了半天发现,某些Unix版本(比如AIX 7.1)的libc会缓存时区信息,重启进程才能生效,可那服务是守护进程,根本不会自己重启。最后我手动杀了进程,结果触发了一连串依赖它的服务崩溃,凌晨三点半,我蹲在机房里一边骂娘一边重启服务。

  机房的空调吹得我膝盖疼,屏幕上的告警还在闪。同事老张端着泡面凑过来:“又踩时区坑了?”我白了他一眼:“你上次不是也在这上面摔过?”他嘿嘿一笑:“我后来学乖了,改时区前先查‘zdump -v /etc/localtime’。”我试了下,发现那台机器的时区文件居然被手动修改过,导致“zdump”显示的时间和实际差了半小时——这他妈谁干的?老张耸耸肩:“可能是三年前那个外包,他改完没测试就跑了。”

  第三个坑是“库文件路径”。我按惯例把新编译的libcurl.so.4放到/usr/local/lib,结果服务启动时报“libcurl.so.4: cannot open shared object file”。用ldd一查,发现服务链接的是/usr/lib/libcurl.so.3——那台机器的/etc/ld.so.conf里没包含/usr/local/lib,而/etc/ld.so.conf.d/下的某个文件又覆盖了默认路径。我原以为“ldconfig -v”能解决,结果发现某些Unix版本(比如HP-UX 11i)的ldconfig不会自动读取/etc/ld.so.conf.d/下的文件,必须手动指定路径。最后我改了/etc/ld.so.conf,跑了“ldconfig”,结果服务还是报错——原来有个旧版本的libcurl.so.4藏在/opt/lib里,被某个环境变量优先加载了。

  第四个坑是“用户权限”。我给新用户“deploy”设置了/bin/bash的shell,结果他执行“sudo”时提示“sudo: command not found”。我查了半天发现,/etc/passwd里他的shell是/bin/bash,可/etc/shells里没包含/bin/bash——某些Unix版本(比如FreeBSD 12)的sudo会检查/etc/shells,如果用户的shell不在里面,就拒绝执行。我加了/bin/bash到/etc/shells,结果部署脚本又报“permission denied”——原来/bin/bash的权限被改成了700,而部署脚本需要它有755权限。我问老张:“谁改的bash权限?”他挠挠头:“可能是安全组,他们上个月做了权限审计。”

  第五个坑是“环境变量继承”。我在/etc/profile里设置了JAVA_HOME,结果部署脚本里echo $JAVA_HOME是空的。我查了半天发现,部署脚本是用“su - deploy”执行的,而“su -”会重新加载/etc/profile,但某些Unix版本(比如IRIX 6.5)的“su -”不会加载/etc/profile.d/下的文件,而JAVA_HOME的配置是在/etc/profile.d/java.sh里。我改了部署脚本,把“su - deploy”改成“su deploy -c 'source /etc/profile; ./deploy.sh'”,结果又报“source: not found”——原来deploy用户的shell是/bin/sh,而/bin/sh在某些Unix版本(比如Tru64 UNIX 5.1)里不支持“source”命令,必须用“. /etc/profile”。

  窗外天快亮了,我盯着屏幕上的“BUILD SUCCESSFUL”直犯困。老张拍了拍我肩膀:“行了,至少这次没宕机。”我撇撇嘴:“可这五个坑,哪个不是老手该知道的?”他笑了:“老手也架不住环境杂啊——Solaris、AIX、HP-UX、FreeBSD、IRIX,每个都有点小脾气,谁记得住所有细节?”我叹了口气:“其实这些坑,优胜劣汰早该解决了——现在谁还用这些老古董?”他摇摇头:“可有些客户就认它们,说稳定。你说气不气人?”

文章配图,仅供参考

  我承认,这事本来能避免——如果我能提前查清楚每个Unix版本的差异,如果我能记得所有旧脚本的坑,如果我能说服客户换新系统。可现实是,我踩了五个坑,熬了一夜,最后只换来一句“下次注意”。下次?下次我可能还会踩新的坑——毕竟,Unix的坑,永远踩不完。

(编辑:站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!