ulimit本质是分层资源管控体系：软限制（-s）为当前生效值，用户可在硬限制（-h）内调整；硬限制仅root可提升，需同时检查ulimit -sn和-hn；/etc/security/limits.conf需pam启用、匹配登录方式（如su -）、桌面环境需logind.conf配置，systemd服务须在unit中设limitnofile；还需确保内核级fs.file-max足够。
Linux 的 ulimit 不是“设个数就完事”，它本质是一套分层、有权限边界、依赖加载机制的资源管控体系。安全有效的设置，核心在于理解软硬限制关系、作用范围差异和生效路径是否闭环。
先搞清软限制和硬限制的区别
软限制（-S）是当前进程实际遵守的上限，普通用户可调低或在硬限内调高；硬限制（-H）是系统设定的绝对天花板，只有 root 能提升。比如执行 ulimit -n 65535 实际等价于 ulimit -Sn 65535，若此时 ulimit -Hn 是 1024，命令会失败并报 “Operation not permitted”。所以查限制必须同时看两个值：ulimit -Sn 和 ulimit -Hn。
/etc/security/limits.conf 配置后不生效？检查三件事
该文件只是配置源，不是自动生效开关。真正起作用需满足：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- PAM 模块已启用：确认
/etc/pam.d/sshd或/etc/pam.d/login中存在session required pam_limits.so或@include common-session - 登录方式匹配：SSH 登录、控制台登录通常走 PAM；但
su username（不带 -）不触发 PAM，要用su - username才加载 limits - 图形界面绕过 PAM：GNOME/KDE 等桌面环境默认不读 limits.conf，需额外在
/etc/systemd/logind.conf中设DefaultLimitNOFILE=65535并重启systemd-logind
systemd 服务完全无视 limits.conf
用 systemctl start nginx 启动的服务，其进程由 systemd 直接 fork，不经过 PAM 认证流程，因此 limits.conf 对它无效。必须在服务单元中显式声明：
- 新建
/etc/systemd/system/nginx.service.d/override.conf - 写入：
[Service]<br>LimitNOFILE=65535<br>LimitNPROC=4096
- 执行
systemctl daemon-reload && systemctl restart nginx - 验证：用
systemctl show nginx | grep LimitNOFILE或查进程实际值cat /proc/$(pidof nginx)/limits | grep "Max open files"
别漏掉内核级总容量：fs.file-max
ulimit -n 控制单进程打开文件数，而 fs.file-max 是整个系统能分配的文件描述符总数。如果后者太小，即使每个进程都设到 65535，系统也可能因全局耗尽而拒绝新分配。查看： cat /proc/sys/fs/file-max；临时调整：sysctl -w fs.file-max=100000；永久生效：在 /etc/sysctl.conf 中添加 fs.file-max = 100000 并运行 sysctl -p。
