在 CentOS 系统中,ulimit 设置“失效”是运维中非常常见的问题,通常不是 ulimit 本身无效,而是设置方式或生效范围不对。下面按最常见原因 → 排查方法 → 正确做法系统说明。
| 原因 | 是否常见 | 说明 |
|---|---|---|
| 只对当前 shell 生效 | ✅ 最常见 | ulimit 是 进程级 限制 |
修改了 /etc/security/limits.conf 但没生效 |
✅ 常见 | 依赖 pam_limits.so |
| systemd 服务不读 limits.conf | ✅ 非常常见 | CentOS 7+ 尤其容易出现 |
用 su / sudo 切换用户 |
✅ 常见 | 可能丢失 limits |
| 内核参数限制 | ⚠️ 较少 | fs.file-max 等 |
| 配置文件语法错误 | ⚠️ | 少了 * 或写错项 |
ulimit 不是系统全局配置,而是:
限制当前 shell 及其子进程的资源
✅ 修改后:
/etc/security/limits.conf 依赖 PAM
grep pam_limits.so /etc/pam.d/system-auth
grep pam_limits.so /etc/pam.d/login
✅ 正确情况下应有:
session required pam_limits.so
如果 没有,limits.conf 不会生效。
# 错误示例
vim /etc/security/limits.conf
ulimit -n # 看不到变化
✅ 必须:
exit
ssh user@host
ulimit -n
普通用户 必须重新登录 root 有时也需要
✅ 这是 CentOS 7+ 最常见“失效”原因
systemctl show your_service | grep Limit
例如:
systemctl show nginx | grep LimitNOFILE
结果通常是:
LimitNOFILE=1024
systemd 启动时 直接忽略 limits.conf
[Service]
LimitNOFILE=65535
LimitNPROC=65535
然后:
systemctl daemon-reexec
systemctl restart your_service
vim /etc/systemd/system.conf
DefaultLimitNOFILE=65535
DefaultLimitNPROC=65535
或用户级:
vim /etc/systemd/user.conf
然后:
systemctl daemon-reexec
reboot # 或重启服务
su - www
ulimit -n
可能:
ssh www@localhost
ulimit -n
或:
sudo -i
ulimit -n
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
⚠️ 注意:
* 不包括 root(有时)root soft nofile 65535
root hard nofile 65535
cat /proc/sys/fs/file-max
sysctl -w fs.file-max=1000000
vim /etc/sysctl.conf
fs.file-max = 1000000
sysctl -p
# 1. 当前限制
ulimit -a
# 2. 当前进程限制
cat /proc/$$/limits
# 3. systemd 服务
systemctl show 服务名 | grep Limit
# 4. limits.conf
cat /etc/security/limits.conf
# 5. PAM
grep pam_limits /etc/pam.d/*
CentOS 下 ulimit 失效,90% 是因为:
- 设置方式不对
- systemd 服务没单独配置
- 没有重新登录
如果你愿意,可以把 你的 CentOS 版本 + 具体失效场景(比如 Nginx / Oracle / Java) 发出来,我可以直接给你精准配置方案。