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

　　去年九月给某金融公司搭Unix环境，踩的坑现在想起来还牙疼——明明都是十年老手，结果被五个基础问题按在地上摩擦。第一个坑是/etc/hosts文件权限，我原以为这破玩意儿早该没人搞错了，结果测试环境死活连不上数据库，抓包发现DNS解析超时。最后发现是某个运维同事把/etc/hosts权限改成了600，说怕被人篡改——可你改权限前倒是看看systemd-resolved的依赖啊！凌晨三点蹲在机房改权限，凉掉的茶在键盘上凝成水珠，隔壁工位的小王还在跟媳妇视频说“今晚肯定能回家”。

　　第二个坑更离谱：glibc版本冲突。客户非要装自研的中间件，结果编译时提示“undefined reference to `__strdup’”。我第一反应是“这特么不是GLIBC_2.2.5才有的函数吗？”，结果ldd一查，系统glibc是2.17，中间件硬编码了2.2.5的符号表。更绝的是，客户说“我们之前在CentOS 6上跑得好好的”——大哥，CentOS 6的glibc是2.12啊！最后没办法，只能用patchelf硬改二进制文件的依赖库路径，站长平台里存了半年的截图显示，这招在生产环境只撑了十八天就崩了。

　　第三个坑是时区设置。客户要求所有服务器必须用上海时区，结果部署脚本里漏了`ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime`。测试时没发现问题，因为运维手动改过；到了生产环境，cron任务全乱套——本来该凌晨三点跑的备份，结果在UTC时间三点跑，把数据库锁了半小时。最搞笑的是，客户监控系统显示“备份任务成功率100%”，因为脚本里没写错误处理，锁表超时直接退出，监控还当成功。等我发现时，竞对站已经改了三次标题，流量曲线都快成心电图了。

文章配图，仅供参考

　　第五个坑是内核参数调优。客户说“我们要高并发”，我照着网上抄了套`net.ipv4.tcp_max_syn_backlog=8192`、`net.core.somaxconn=65535`的配置，结果重启后ssh连不上服务器了。抓包发现SYN包全被丢弃，原来忘了调`net.ipv4.tcp_syncookies=1`。更绝的是，某些云厂商的虚拟机对`net.ipv4.ip_local_port_range`有限制，设成`1024 65535`会报错——我原以为这是基础操作，结果在阿里云上栽了跟头，最后只能改成`32768 60999`。

　　这些坑有个共同点：看似是“基础操作”，但每个都藏着细节。比如/etc/hosts权限，你以为改个数字没事，可systemd-resolved可能依赖它；glibc版本，你以为“向下兼容”，可中间件可能硬编码符号表；ulimit，你以为改/etc/security/limits.conf就够了，可systemd服务有自己的限制。我敢打包票，就算让Linus本人来搭环境，也得踩至少两个——因为这些坑不是“技术问题”，是“经验盲区”。

　　现在每次搭环境，我都先列个检查清单：先查/etc/hosts权限，再确认glibc版本，然后看时区设置，接着检查ulimit，最后调内核参数。就算客户催得急，也得把这五步走完——慢五分钟，可能省五小时排查。至于那些“我听说”“网上说”的优化方案，我现在都先在测试环境跑三天，确认没问题再上生产——毕竟，被坑过一次，就知道“优胜劣汰”的道理了：能活下来的配置，都是踩过坑的。

　　不过话说回来，这些坑也让我明白：Linux老手和新手的区别，不是会不会踩坑，而是踩坑后能不能记住——我电脑里存了三百七十二张错误截图，就是为下次少踩点。至于那些“绝对没问题”的方案？呵呵，我信个鬼——上次有人说“这个脚本绝对兼容所有Linux发行版”，结果在Alpine上跑崩了，因为Alpine用musl不是glibc。现在我只信两件事：一是自己测过的，二是踩过坑的。

（编辑：站长网）

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