debian ulimit不生效原因

在 Debian 系统中，ulimit 不生效是一个非常常见的问题，通常不是命令本身的问题，而是作用范围、配置位置或系统机制导致的。下面按最常见原因 → 排查方法 → 解决方法来说明。

一、最常见原因总结（先看这个）

只在当前 shell 生效，退出后失效
修改了 /etc/security/limits.conf，但 PAM 没启用
systemd 服务不受 limits.conf 控制
修改的是 soft limit，但被 hard limit 限制
ulimit 对非root用户才生效，root 例外
在脚本 / Docker / 容器中设置不生效
参数写错或写到了错误文件

二、ulimit 的本质（很重要）

ulimit 只对当前 shell 及其子进程生效
它不是系统级全局配置
系统级限制由以下机制控制：
- PAM（limits.conf）
- systemd（Limit*）
- 内核参数

三、不同场景 & 对应解决方案

✅ 场景 1：登录用户 ulimit 不生效

配置文件

/etc/security/limits.conf
/etc/security/limits.d/*.conf

示例：

* soft nofile 65535
* hard nofile 65535

但必须满足：

✅ PAM 已启用

检查：

grep pam_limits /etc/pam.d/common-session
grep pam_limits /etc/pam.d/common-session-noninteractive

应看到：

session required pam_limits.so

如果没有：

apt install libpam-modules

⚠️ 修改后 必须重新登录

✅ 场景 2：SSH 登录不生效

SSH 默认不加载某些环境

解决：

vi /etc/ssh/sshd_config

确保：

UsePAM yes

重启：

systemctl restart ssh

✅ 场景 3：systemd 服务不生效（重点）

这是 Debian 10+ 最常见原因

limits.conf 对 systemd 服务无效！

例如：

systemctl restart nginx

正确做法（systemd 专用）：

systemctl edit nginx

写入：

[Service]
LimitNOFILE=65535

生效：

systemctl daemon-reload
systemctl restart nginx

验证：

cat /proc/$(pgrep nginx | head -1)/limits

✅ 场景 4：root 用户不生效

默认：

root 不受 limits.conf 中 * 的限制

必须显式写：

root soft nofile 65535
root hard nofile 65535

✅ 场景 5：Docker / 容器不生效

Docker 容器：

docker run --ulimit nofile=65535:65535 ...

docker-compose：

ulimits:
  nofile:
    soft: 65535
    hard: 65535

✅ 场景 6：脚本中 ulimit 无效

❌ 错误：

ulimit -n 65535
./app &

✅ 正确：

ulimit -n 65535
exec ./app

或直接：

( ulimit -n 65535; ./app )

四、快速排查 checklist

# 当前限制
ulimit -a

# 进程实际限制
cat /proc/<pid>/limits

# PAM 是否启用
grep pam_limits /etc/pam.d/*

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

五、一句话总结

Debian 下 ulimit 不生效，90% 是因为 systemd 或 PAM 没配置对，而不是 ulimit 命令本身的问题。

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

Debian 版本
想限制什么（nofile / nproc / core）
是用户、服务还是容器

我可以直接给你一份可复制的配置。