ulimit 临时生效，永久修改需同步配置 limits.conf、systemd service 文件及 sysctl 参数；否则重启后失效，因 ulimit 仅作用于当前 shell 会话，ssh 登录依赖 pam 的 limits.d 配置，systemd 服务需显式设置 limitnofile，且内核参数 fs.nr_open 必须不低于用户设定值。
ulimit 只能临时生效，要永久修改 CentOS 7 的资源使用上限，必须组合修改多个配置点，否则改了也白改。
为什么 ulimit 设置后重启就失效？
因为 ulimit 是 shell 级别的运行时限制，只对当前会话及其子进程有效。用户重新登录、服务重启、systemd 启动的服务，全部不继承这个值。
- SSH 登录、console 登录走的是 PAM 认证流程，真正起作用的是
/etc/security/limits.conf和/etc/security/limits.d/*.conf - systemd 服务绕过 PAM，默认忽略
limits.conf，必须在 service 文件里显式声明LimitNOFILE等参数 -
root用户受/etc/security/limits.d/20-nproc.conf单独约束，*条目不覆盖它
/etc/security/limits.conf 怎么写才生效？
写错位置或格式，ulimit -n 就永远显示旧值。关键点有三个：
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 顺序重要：
limits.d/下的文件按字母序加载，20-nproc.conf会覆盖limits.conf里同名项（比如nproc） - 用户匹配要精确：用
username比*更可靠；组要用@groupname格式 - 类型必须明确：
soft和hard要分开写，且hard不能低于soft；例如：kass soft nofile 65536和kass hard nofile 65536 - 生效需重新登录：改完后必须退出当前 session 再登录，或者用
su - kass切换验证
systemd 服务的资源限制怎么配？
即使 limits.conf 改好了，systemctl start nginx 启动的服务仍可能卡在默认的 1024 个文件描述符——因为它压根不读那个文件。
- 编辑对应 unit 文件，如
/etc/systemd/system/nginx.service - 在
[Service]段下添加：LimitNOFILE=65536、LimitNPROC=65536 - 注意：systemd 219+ 版本支持
LimitCORE、MemoryLimit等，但 CentOS 7 自带 systemd 219，MemoryLimit不可用 - 改完必须执行：
systemctl daemon-reload && systemctl restart nginx
系统级最大值 fs.file-max 和 fs.nr_open 必须同步调
如果只改用户限制，而内核允许的全局上限太低，ulimit -n 65536 会静默失败，实际还是旧值。
- 查当前值：
cat /proc/sys/fs/file-max和cat /proc/sys/fs/nr_open -
nr_open必须 ≥ 你设的单用户nofile值，否则limits.conf中的高值会被截断 - 在
/etc/sysctl.conf里加两行：fs.file-max = 6553600和fs.nr_open = 2000000 - 执行
sysctl -p生效，无需重启
改完别急着验证，先确认你是用什么方式启动目标进程的：交互式 shell？systemd 服务？还是 docker 容器？不同路径依赖的配置文件完全不同。漏掉任意一环，上限就卡死在 1024。
