ulimit设置不生效的根本原因是软硬限制冲突、pam加载时机不当及systemd绕过机制；需先提升硬限制再设软限，且systemd服务须单独配置limitnofile等参数。
Linux 进程资源限制不是“设了就生效”，ulimit 的软硬限制、PAM 加载时机、systemd 服务绕过机制，三者不协同，90% 的配置失败都出在这里。
为什么 ulimit -n 65536 立刻报错 “operation not permitted”？
这不是命令写错了，而是你正试图把软限制（-S）提得超过当前硬限制（-H）。普通用户无权提升硬限制，系统会直接拒绝。
-
ulimit -H -n查看当前硬限制（比如是 1024），你不能用ulimit -n 65536一步到位 - 必须先确保硬限制已提高（需 root 修改
/etc/security/limits.conf），再重新登录会话 - 即使 root 改了配置，也必须退出当前 SSH 或终端——
ulimit是会话级的，不会热加载 - 常见错误现象：
ulimit: max user processes: cannot modify limit: operation not permitted，本质都是软限 > 硬限
永久生效却对 Nginx / Redis / Java 服务无效？
因为这些服务大多由 systemd 启动，而 /etc/security/limits.conf 对 systemd 管理的进程默认不生效——它只影响 PAM 登录会话启动的 shell 进程。
- 对全局生效：编辑
/etc/systemd/system.conf，取消注释并修改这两行：DefaultLimitNOFILE=655360 DefaultLimitNPROC=655360
- 对单个服务生效（推荐）：编辑
/usr/lib/systemd/system/nginx.service，在[Service]段下添加：LimitNOFILE=65536 LimitNPROC=65536
- 改完必须执行：
sudo systemctl daemon-reload && sudo systemctl restart nginx - 验证方式不是
ulimit -n，而是查进程实际限制：cat /proc/$(pidof nginx)/limits | grep "Max open files"
ulimit -l unlimited 为什么在 Ubuntu 上经常不生效？
memlock 限制用于锁定内存（如 RDMA、DPDK、实时音频），但 Ubuntu/Debian 默认禁用 pam_limits.so 的 session 模块，导致 limits.conf 中的 memlock 配置被跳过。
- 第一步：确认
/etc/pam.d/common-session包含这一行：session required pam_limits.so
- 第二步：在
/etc/security/limits.conf中加：* soft memlock unlimited * hard memlock unlimited
- 第三步（终极兜底）：若仍无效，直接写入内核参数：
echo '* - memlock unlimited' | sudo tee -a /etc/security/limits.conf，再配合 reboot ——某些云主机或容器环境必须重启才触发完整 PAM 初始化
真正容易被忽略的点：ulimit 不是“系统级开关”，它是 shell 层的资源闸门；而 systemd、docker、supervisord 都可能绕过它。别只盯着 limits.conf，先确认你的进程到底是谁拉起来的、走的是哪条初始化路径。
