ulimit临时设置仅对当前shell有效，退出即失效；永久生效需分三层配置：用户级（/etc/security/limits.conf+pam）、systemd服务级（/etc/systemd/system.conf或.service.d/）、系统级（sysctl.conf中fs.file-max）。
ulimit 临时改完就失效？必须分清 soft/hard 和生效范围
直接运行 ulimit -n 65535 只对当前 shell 及其子进程有效，退出或新开终端就回退。关键不是“能不能设”，而是“设给谁、在哪生效”。CentOS 7 的限制分三层：shell 进程级、登录用户级、systemd 服务级，混用会导致看似设了却没效果。
-
ulimit -S设 soft limit（可临时超限但会警告），ulimit -H设 hard limit（硬性上限，普通用户无法突破） - 非 root 用户只能调低 hard limit 或在 soft ≤ hard 范围内调整；root 才能抬高 hard limit
- 仅靠
ulimit命令无法让新登录用户或 systemd 服务继承设置
/etc/security/limits.conf 改了为啥不生效？PAM 加载顺序和用户类型是关键
该文件只对通过 PAM 登录的交互式用户（比如 SSH 登录、console 登录）生效，且依赖 pam_limits.so 模块加载。CentOS 7 默认启用它，但有两个常见陷阱：
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
- 如果用户属于
wheel组且配置了auth required pam_wheel.so deny group=wheel，limits 可能被跳过 -
/etc/security/limits.d/*.conf按字母序加载，20-nproc.conf会覆盖limits.conf中的nproc设置（尤其影响最大线程数） - 不要用
*笼统匹配所有用户——若需针对特定服务用户（如nginx），明确写成nginx行，否则可能被其他规则覆盖
systemd 服务的 ulimit 必须单独配，limits.conf 对它完全无效
CentOS 7 用 systemd 管理服务后，/etc/security/limits.conf 对 systemctl start xxx 启动的服务不起作用。必须走 systemd 自己的机制：
- 全局生效：编辑
/etc/systemd/system.conf，修改DefaultLimitNOFILE=65535等项，改完要重启 host（不是 reload） - 单服务生效：在
/etc/systemd/system/<service>.service.d/limit.conf</service>里加[Service]段，写LimitNOFILE=65535，然后systemctl daemon-reload && systemctl restart <service></service> - 验证是否生效：查
cat /proc/<pid>/limits | grep "Max open files"</pid>，别只信ulimit -n输出
系统级文件描述符上限 fs.file-max 也要同步调，否则 ulimit 再大也卡住
ulimit -n 是进程级上限，fs.file-max 是整个系统的总句柄池。如果后者太小，即使单个进程设到 65535，系统也会因全局耗尽而报 Too many open files。
- 临时调高：
sysctl -w fs.file-max=1048576 - 永久生效：往
/etc/sysctl.conf加fs.file-max = 1048576，再sysctl -p - 注意：这个值不能无脑设太大，每文件描述符占约 1KB 内核内存，100 万 ≈ 1GB 内存开销
limits.conf、systemd service 配置、sysctl.conf 这三处常被漏掉一两个，结果查半天发现只是某一层没打通。
