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

发布时间：2026-10-12 14:27:25 所属栏目：Unix 来源：DaWei

导读：　　Linux老手也常踩的5个Unix环境搭建坑——这标题不是标题党，是我最近在给某券商核心清算系统做Java 17+GraalVM迁移时实测翻车的真实记录。客户生产环境是CentOS 7.9内核3.10.0-1160，我们按文档配好cgroup v1+system

　　Linux老手也常踩的5个Unix环境搭建坑——这标题不是标题党，是我最近在给某券商核心清算系统做Java 17+GraalVM迁移时实测翻车的真实记录。客户生产环境是CentOS 7.9内核3.10.0-1160，我们按文档配好cgroup v1+systemd的JVM内存限制，结果跑三天后OOM Killer连续干掉三个进程——查日志才发现/sys/fs/cgroup/memory/jvm.slice/memory.limit_in_bytes被systemd偷偷重写了两次，因为/usr/lib/systemd/system/jvm.service里漏写了MemoryAccounting=true。这种配置冲突连Red Hat官方KB#289347都只字未提。

文章配图，仅供参考

　　坑一：/etc/security/limits.conf对systemd服务根本无效。我上周帮杭州某AI初创公司调TensorFlow Serving的ulimit，他们把nofile设到65536，但ps auxf看实际进程还是1024——原因？systemd 219之后默认绕过PAM limits模块，必须手动在/etc/systemd/system.conf里加DefaultLimitNOFILE=65536，还得执行systemctl daemon-reload && systemctl restart systemd-logind。他们用的是Ubuntu 22.04.3，systemd版本249.11-0ubuntu3.12，这个坑连Canonical工程师在2023年11月的Launchpad bug #2042882里才补上一句备注。

　　坑二：/dev/shm默认大小4MB会悄悄拖垮PostgreSQL 15。今年3月我在某政务云项目实测，pg_stat_statements扩展开启后，shared_buffers设为4GB时，PostgreSQL启动直接报错“could not resize shared memory segment”。strace发现它试图在/dev/shm下创建pg_stat_XXXX文件，而该目录挂载参数是size=4M——这是RHEL 8.7 /usr/lib/tmpfiles.d/shm.conf的默认值。临时解决？mount -o remount,size=256M /dev/shm。但更狠的是：CentOS Stream 9把shm默认改成了tmpfs且size=64M，可Debian 12还是锁死4M。这差异没人写进任何兼容性矩阵。

　　坑三：locale-gen生成的UTF-8编码不等于glibc真正加载的编码。上周五凌晨两点，某跨境支付API突然返回乱码“ç”和“é”，debug半小时发现LANG=en_US.UTF-8没错，locale -a显示en_US.utf8也存在——问题出在glibc 2.35+引入的locale-archive缓存机制。他们用的是Alpine 3.18（musl libc），但部署脚本里误装了glibc-compat包，导致localedef -i en_US -f UTF-8 en_US.UTF-8生成的文件根本没被musl读取。最终方案是删掉/usr/share/i18n/locales/en_US，改用apk add --no-cache tzdata，靠/etc/TZ硬编码时区——这招连Docker官方PHP镜像都不认。

　　坑四：chrony与ntpd共存时ntpdate仍可能触发时间跳变。去年12月我在某银行核心交易网关抓包发现，虽然systemctl disable ntpd且chronyd -q已执行，但某开发留下的crontab还在每天3:15跑ntpdate -s time.nist.gov。chronyd本身不会拦截ntpdate请求，而ntpd残留的socket文件/var/run/ntpd.pid虽被删，/var/lib/chrony/drift却被ntpdate的-S参数强行覆盖——导致chronyd重启后漂移补偿失准。实测误差从±2ms飙到±87ms，触发了Redis哨兵的时钟跳跃告警。这问题在chrony 4.3 release note第7行藏着一行小字：“ntpdate compatibility remains intentional but unsupported”。

　　坑五：/proc/sys/net/core/somaxconn设置被Docker守护进程覆盖。上周二在Kubernetes节点上，我看到nginx pod的listen backlog始终卡在128，明明宿主机sysctl.conf写了net.core.somaxconn = 65535，也执行了sysctl -p。tcpdump抓包发现，dockerd 24.0.7每次拉起容器都会重置/proc/sys/net/core/somaxconn到1024——源码在containerd的oci/runtime/spec_linux.go里hardcode了这个值。后来翻到2024年2月的containerd PR#8921才加了--sysctl参数支持，但Helm chart模板还没同步更新。所以现在我的折中方案？直接在pod的securityContext里加sysctls: [{name: net.core.somaxconn, value: "65535"}]——但别忘了，AWS EKS 1.28 AMI的Amazon Linux 2 kernel 5.10.211压根不支持该字段校验。

　　Linux老手也常踩的5个Unix环境搭建坑——我认为它优点在新技术。

　　我刚收到邮件，客户说要把GraalVM换成Zulu JDK 21。算了，先喝杯咖啡。

（编辑：站长网）

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