Debian ulimit为何重启失效

在 Debian（以及大多数 Linux 发行版）中，ulimit 设置重启后失效是正常现象，这是由 ulimit 的设计和 Linux 的进程模型决定的。下面分点说明原因，并给出正确的持久化方法。

一、为什么 ulimit 重启会失效？

1. ulimit 是 进程级 设置

• ulimit 只影响当前 shell 进程及其子进程
• 它不是系统全局配置
• 一旦进程退出（如重启），设置就消失

ulimit -n 65535

只对你当前 shell 会话有效。

2. 重启后进入新的 shell

• 重启后系统重新初始化进程
• ulimit 不会自动恢复之前的设置
• 除非写入启动脚本或系统配置

二、常见错误做法（不会持久化）

❌ 只在终端执行

ulimit -n 65535

❌ 写在 ~/.bashrc（不推荐）

只对交互式 shell 有效，对服务无效。

三、Debian 正确的持久化方式 ✅

✅ 方法一：使用 /etc/security/limits.conf（最常用）

适用于：

• 登录用户
• 通过 PAM 启动的进程

1️⃣ 编辑配置

sudo vim /etc/security/limits.conf

追加：

* soft nofile 65535
* hard nofile 65535

或指定用户：

www-data soft nofile 65535
www-data hard nofile 65535

2️⃣ 确保 PAM 启用

检查：

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

如果没有，添加：

session required pam_limits.so

✅ 重启后生效

✅ 方法二：systemd 服务（非常重要）

⚠️ Debian 使用 systemd，limits.conf 对 systemd 服务默认无效

针对某个服务

sudo systemctl edit nginx

写入：

[Service]
LimitNOFILE=65535

然后：

sudo systemctl restart nginx

✅ 方法三：全局 systemd 设置（影响所有服务）

sudo vim /etc/systemd/system.conf

DefaultLimitNOFILE=65535

sudo vim /etc/systemd/user.conf

DefaultLimitNOFILE=65535

然后：

sudo systemctl daemon-reexec
sudo reboot

四、如何验证是否生效？

查看当前 shell

ulimit -n

查看某个进程

cat /proc/$(pidof nginx)/limits | grep "Max open files"

五、常见误区总结

六、一句话总结

ulimit 重启失效是正常行为，必须通过 limits.conf 或 systemd 配置才能持久化。

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

• 你用的是 Debian 哪个版本
• 是 普通用户 / 服务 / Docker / 云服务器
• 想改的是 nofile / nproc / stack / mem

我可以给你精确到命令级别的方案。