为什么centos ulimit失效

在 CentOS 中，ulimit 经常让人感觉“失效”，通常不是命令本身的问题，而是作用范围、配置位置或进程启动方式导致的。下面按最常见原因逐一说明。

一、ulimit 只对“当前 shell 及其子进程”生效（最常见）

ulimit 是 shell 内置命令，不是系统全局配置。

ulimit -n 65535

只影响：

当前 shell
当前 shell 启动的子进程

不会影响：

已存在的进程
其他终端
系统服务（systemd 管理的）

✅ 验证：

ulimit -n
# 新开一个终端，再 ulimit -n，可能还是 1024

二、修改了 /etc/profile 或 ~/.bashrc，但服务不是从 shell 启动的

很多人写：

# /etc/profile
ulimit -n 65535

然后发现：

SSH 登录后生效
Nginx / MySQL / Java 服务不生效

原因：

systemd 服务 不读取 /etc/profile
服务由 systemd 直接拉起

✅ 正确方式（CentOS 7+）：

方法 1：systemd 服务级限制

# /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=65535

然后：

systemctl daemon-reload
systemctl restart nginx

三、/etc/security/limits.conf 没生效（PAM 问题）

* soft nofile 65535
* hard nofile 65535

但发现没用，常见原因：

1. 进程不是“登录用户”启动的

limits.conf 依赖 PAM

只对 login shell 生效
对 systemd 服务 不生效

2. 没加 pam_limits.so

检查：

grep pam_limits /etc/pam.d/system-auth

应包含：

session required pam_limits.so

四、systemd 有“更高优先级”的限制

CentOS 7/8 中：

systemd 默认限制会覆盖 ulimit

例如：

systemctl show nginx | grep LimitNOFILE

如果看到：

LimitNOFILE=1024

那你改 ulimit 是没用的。

✅ 必须改 systemd 配置

五、修改了配置但没重启 / 重登录

以下情况需要：

重新登录（limits.conf）
重启服务（systemd）
重启进程（ulimit）

只改文件不重启 = 不生效

六、内核参数限制（极端情况）

cat /proc/sys/fs/file-max

如果太小：

sysctl -w fs.file-max=1000000

七、快速排查清单 ✅

# 当前进程限制
cat /proc/<pid>/limits

# systemd 限制
systemctl show <service> | grep Limit

# 当前 shell
ulimit -a

总结一句话

CentOS 上 ulimit“失效”，99% 是因为：你改的地方，进程根本没读到。

如果你愿意，可以告诉我：

CentOS 版本（6 / 7 / 8）
什么服务（Nginx / Java / MySQL）
你改了哪些文件

我可以直接给你最正确的配置方式。