ulimit -n临时设置重启后失效，因其仅作用于当前shell会话；systemd服务需在unit文件中配置limitnofile并重载，/etc/security/limits.conf对pam登录会话生效但不适用于systemd。
为什么ulimit -n临时设置重启后失效
因为ulimit命令只影响当前shell及其子进程，属于会话级限制，系统重启、用户登出或新登录都会重置为默认值。常见现象是：你刚执行了ulimit -n 65536，启动服务正常；但用systemctl start xxx拉起进程时，依然报Too many open files——这是因为systemd管理的服务不继承你的交互式shell限制。
/etc/security/limits.conf配置不生效的常见原因
该文件只对PAM-aware登录会话生效（如SSH登录、图形界面登录），且需满足几个前提条件：
- 确保
pam_limits.so已启用：检查/etc/pam.d/common-session或/etc/pam.d/sshd中存在session required pam_limits.so - 不能对root用户使用
*通配符：必须显式写root soft nofile 65536和root hard nofile 65536 - soft/hard限制要成对设置，且soft ≤ hard；仅设soft可能被hard截断
- 用户名必须与实际登录用户一致（例如用
sudo -i切换的root不算“登录用户”，需单独配root）
systemd服务如何正确设置LimitNOFILE
对于由systemd管理的服务（绝大多数现代Linux服务），/etc/security/limits.conf完全不起作用。必须在service unit中显式声明：
[Service] LimitNOFILE=65536
注意以下细节：
- 修改后必须执行
sudo systemctl daemon-reload，否则配置不加载 - 若服务已运行，需
sudo systemctl restart xxx而非reload - 可设为
LimitNOFILE=infinity，但实际受内核/proc/sys/fs/nr_open上限约束（默认1048576） - 不要在
[Unit]或[Install]节下写LimitNOFILE，无效
验证当前进程真实打开数限制的方法
别只信ulimit -n输出——它只显示当前shell的软限制。要确认某个具体进程的实际限制，得查其/proc入口：
- 先用
ps aux | grep your-process拿到PID - 再执行
cat /proc/<code>PID/limits | grep "Max open files" - 输出类似
Max open files 65536 65536 files才表示真正生效 - 如果看到
1024 4096，说明配置没打到这个进程上，优先排查systemd unit或limits.conf的适用范围
内核级全局上限/proc/sys/fs/file-max也要留意，它决定整个系统能分配多少文件句柄；如果单个进程设得再高，但这里只有65536，那也白搭。
