linux用户资源限制需分场景：登录会话用limits.conf配合pam_limits.so（需重登录生效），systemd服务须配置limitnofile等unit参数，临时调试用ulimit命令，三者互不相通。
Linux 中限制用户进程资源配额，核心是分场景选择合适机制：普通用户登录会话用 /etc/security/limits.conf，systemd 托管的服务必须走 unit 文件，临时调试则直接用 ulimit。三者不互通，漏配就无效。
针对用户登录会话（如 SSH、su、图形终端）
这是最常用、也最容易出错的配置方式。关键点是：配置写对、PAM 加载正常、用户必须重新登录才生效。
- 编辑
/etc/security/limits.conf或更推荐的/etc/security/limits.d/10-user-limits.conf - 按格式写入，例如限制用户
appuser最多打开 8192 个文件、最多运行 2048 个进程：appuser soft nofile 8192<br>appuser hard nofile 8192<br>appuser soft nproc 2048<br>appuser hard nproc 2048
- 软限制（
soft）是当前生效值，用户可自行调低；硬限制（hard）是上限，仅 root 可提升 - 确认 PAM 已启用：
/etc/pam.d/common-session中需含session required pam_limits.so - 验证：退出当前会话，全新 SSH 登录后执行
ulimit -n和ulimit -u
针对 systemd 管理的服务（如 nginx、redis、Java 应用）
/etc/security/limits.conf 对 systemd 启动的服务完全无效。必须在服务单元中显式声明。
- 查服务当前 unit 路径：
systemctl show myapp.service | grep FragmentPath - 新建覆盖目录和配置文件：
sudo mkdir -p /etc/systemd/system/myapp.service.dsudo vi /etc/systemd/system/myapp.service.d/limits.conf - 写入资源限制，例如：
[Service]<br>LimitNOFILE=65536<br>LimitNPROC=4096<br>MemoryMax=2G
- 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart myapp.service - 验证：
systemctl show myapp.service | grep Limit或检查/proc/PID/limits
临时调试或应急限制（当前 Shell 有效）
适合测试参数、快速压制异常进程，但退出终端即失效，不能用于生产长期控制。
- 查看全部当前限制：
ulimit -a - 设单个用户最大进程数为 1024：
ulimit -u 1024 - 设文件描述符上限为 4096：
ulimit -n 4096 - 禁止 core dump：
ulimit -c 0 - 注意：普通用户只能降低自己的软限制；要提升硬限制，必须 root 权限且当前 shell 有权限（如已登录为 root 或用
sudo -i）
特别注意几个常见失效原因
很多配置“写了却没生效”，往往卡在这几处：
-
*不匹配 root 用户 —— 若需限制 root，必须单独加root soft nproc 65535等行 - systemd 服务未重载配置：
daemon-reload必须执行，且要restart而非reload - 内核级总限制低于用户级设置，例如：
cat /proc/sys/kernel/pid_max若为 32768，而你设了nproc 65535，实际仍被截断 - 容器环境（Docker/Podman）中，宿主机 limits.conf 无效，需用
--ulimit参数启动容器，或在容器内单独配置 - 某些发行版（如较新 Ubuntu）默认禁用
pam_limits.so，需手动检查并启用
