Mastering ulimit: Prevent Common Limits Pitfalls in SysVinit, Systemd, and Containers

SysVinit 下的 ulimit 如何生效

在 SysVinit 时代，需要通过特殊配置让 ulimit 生效，通常在

/etc/inittab

中为 1 号进程的子进程设置 limit，配置文件仅适用于 SysVinit，且需重启后生效。该配置会影响如 sshd 等子进程的 limit，可通过检查子进程的实际 limit 来验证。

Systemd 下的 ulimit 如何生效

Systemd 将 limit 配置迁移到

/etc/systemd/system.conf

，需要重启后生效。不同于 SysVinit，Systemd 的配置直接影响 1 号进程本身的 limit，可通过查看

/proc/1/limits

判断是否配置正确。

疑难杂症

1. 仅修改 /etc/initscript 不足，很多应用会使用 PAM (/etc/security/limits.conf)

某些任务（如 cron）会通过 PAM 读取

/etc/security/limits.conf

，导致原有 limit 被覆盖。解决办法是在该文件中显式定义所需的 limit。

常用会使用 PAM 的应用包括

su

、

sudo

、

cron

、

login

、

sshd

等。

2. 在 Debian 系统中， * 通配符不匹配 root 用户。

由于该行为，使用 console 以 root 登录后重启 sshd，会导致 sshd 继承默认的 limit，进而影响后续通过 ssh 启动的业务。修正方式是为 root 用户单独配置 limit，或在

/etc/security/limits.conf

中加入对应条目。

3. 某些 Systemd 版本在将 max open file 设置为 infinity 时仅得到 65536

该问题是 Systemd 的 bug，解决办法是显式设置

DefaultLimitNOFILE

为具体数值或升级 Systemd。

4. 不同 PAM 版本的默认 limit 处理逻辑不同

在容器环境中，Debian 8 的 PAM 会继承宿主的 soft nofile limit，而 Debian 9 的 PAM 使用编译时的默认值（1024），导致 limit 不一致。解决方案是确保容器镜像中包含正确的

/etc/security/limits.conf

。

排查要点

每个进程的 limit 初始值来源要么是父进程，要么是 PAM，PAM 的优先级更高，抓住这两点即可快速定位问题。

常见问题

1. 如何确认一个应用是否使用了 PAM？检查

/etc/pam.d/

下是否有对应的配置文件。

2. 如何确认当前系统是 SysVinit 还是 Systemd？查看

/sbin/init

的信息即可。

3. 如何在线修改一个进程的 limit 值？使用

prlimit

命令，例如对 sshd 进程进行调整：

<code># 当前 ssh 登录后的 max open file 异常
ssh myhost
ulimit -n -S
1024
ulimit -n -H
1024
# 在线调整 max open file
pgrep -f '/usr/sbin/sshd'
523
prlimit --pid=523 --nofile=1000000
# 重新登录检查
ssh myhost
ulimit -n -S
1000000
ulimit -n -H
1000000</code>

结束语

ulimit 的问题虽表现形式多样，只要掌握其关键点——进程 limit 的来源以及 PAM 的优先级，就能轻松解决。

每个进程的 limit 初始值来源，要么来自它的父进程，要么是来自 PAM，其中 PAM 的优先级更高。