CentOS中修改系统级ulimit需同时配置PAM limits、systemd默认值和内核fs.file-max参数，缺一不可；仅执行ulimit命令仅影响当前会话，重启或新登录即失效。
直接说结论：CentOS 中修改系统级 ulimit 限制，不能只改 ulimit 命令本身——它只是查看/设置当前 shell 的资源上限；真正要让服务、子进程、新登录用户都生效，必须组合修改三处：PAM 配置、systemd 默认值、以及内核级参数。漏掉任意一处，都会出现「明明配置了却没生效」的情况。
为什么 ulimit -n 设置后重启就失效？
因为 ulimit 是 shell 内置命令，只影响当前会话及其子进程。你执行 ulimit -n 65535 后，新开一个终端或 SSH 登录，又回到默认值（通常是 1024）。这不是 bug，是设计使然。
常见错误现象：
• 启动 Nginx 或 Redis 报错 Too many open files
• ulimit -n 显示 65535，但 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 仍是 1024
• 用 sudo -i 切换 root 后，ulimit -n 又变回 1024
/etc/security/limits.conf 配置失效的典型原因
这个文件本身不会自动生效，依赖 PAM 模块加载。容易踩的坑：
• /etc/pam.d/sshd 或 /etc/pam.d/login 缺少 session required pam_limits.so 这一行（CentOS 7/8 默认有，但某些最小化安装或自定义镜像可能被删）
• 使用 su - 切换用户时，PAM 不触发 limits 加载（需用 login 方式或加 -l 参数）
• 配置格式错误：字段间必须用空格或制表符分隔，不能混用；* 和用户名之间不能有空行
• 软硬限制写反：比如 * soft nofile 65535 但没配对应 hard 值，某些服务会拒绝启动
正确写法示例（对所有用户）：* soft nofile 65535* hard nofile 65535* soft nproc 65535* hard nproc 65535
systemd 服务无视 limits.conf？加 LimitNOFILE 就行
CentOS 7+ 默认用 systemd 管理服务，而 systemd 会绕过 PAM limits，用自己的默认值（通常是 4096）。所以即使你改了 limits.conf，Nginx、MySQL 等服务仍卡在旧限制。
解决方法：
• 编辑服务单元文件，如 /etc/systemd/system/mysqld.service
• 在 [Service] 段下添加：LimitNOFILE=65535LimitNPROC=65535
• 执行 sudo systemctl daemon-reload && sudo systemctl restart mysqld
• 验证：cat /proc/$(pgrep mysqld)/limits | grep "Max open files"
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
如果不想改单个服务，可统一设为全局默认：
编辑 /etc/systemd/system.conf，取消注释并修改：DefaultLimitNOFILE=65535DefaultLimitNPROC=65535
然后 sudo systemctl daemon-reload（无需重启）
fs.file-max 和 ulimit 的关系别搞混
fs.file-max 是内核参数，表示整个系统能打开的最大文件描述符总数；ulimit -n 是每个进程的上限。两者是包含关系：
• 如果 fs.file-max 设太小（比如默认的 8192），即使你把 ulimit -n 设到 10 万也没用，进程一开就报错
• 修改方式：
• 临时： sudo sysctl -w fs.file-max=2097152
• 永久：在 /etc/sysctl.conf 加 fs.file-max = 2097152，再运行 sudo sysctl -p
• 查看当前值：cat /proc/sys/fs/file-max
注意：这个值建议设为单个进程最大值 × 预估并发进程数，留 20% 余量。比如你允许每个服务开 65535 个 fd，预计最多跑 20 个同类服务，那 fs.file-max 至少设到 160 万。
实际生效顺序是：内核参数（fs.file-max）→ systemd 默认限制 → PAM limits → shell 当前会话 ulimit。越往后的优先级越高，但前提是前面的不拦路。最容易被忽略的是 PAM 没启用、systemd 没覆盖、或者 fs.file-max 卡死上限——这三个点全通了，才真算改到位。
