ulimit -u 200仅对当前shell会话及其子进程生效，立即限制用户总进程数为200，可快速验证fork炸弹防护效果，登出或新开终端即失效。
ulimit -u 临时限制只对当前会话生效
直接运行 ulimit -u 200 就能把当前 shell 及其后续启动的进程总数卡死在 200。它立刻生效，适合快速验证或应急干预。
常见错误现象：执行 (){ :|:& };: 后几秒就报 bash: fork: Resource temporarily unavailable——说明限制已起作用。
- 该设置不继承到新终端、新 SSH 连接，登出即失效
- root 用户默认不受限，要用
sudo -u alice ulimit -u 150模拟目标用户环境 - 不能设得比当前硬限制还高；若提示
Operation not permitted，说明已触达硬限，需 root 权限或改配置文件
/etc/security/limits.conf 必须软硬限制都写
只写一行 alice nproc 300 是无效的。必须明确区分 soft 和 hard：
alice soft nproc 200 alice hard nproc 300
其中 hard 才是最终拦截 fork 炸弹的防线，soft 只是用户可临时调高的上限（但不能超 hard）。
- 对组生效用
@developers soft nproc 500，慎用通配符*，否则可能误限syslog、dbus等系统账户 - 改完不会自动覆盖已有登录会话，必须让目标用户重新登录（
su - alice也行），再跑ulimit -u确认数值 - 若值没变，大概率是 PAM 没加载，不是配置写错了
pam_limits.so 不启用，limits.conf 就是废纸
检查是否启用模块：grep pam_limits.so /etc/pam.d/{sshd,login,system-auth}。缺了就得手动加：
CentOS/RHEL：session required /lib64/security/pam_limits.so
Debian/Ubuntu：session required /lib/x86_64-linux-gnu/security/pam_limits.so
- 加在
/etc/pam.d/sshd末尾即可覆盖 SSH 登录；加在system-auth是通用方案 - 不用重启 sshd 或 reboot，新连接自动按新规则加载
- 旧连接仍沿用原限制，所以验证一定要新开终端或
su -
容器里 ulimit -u 完全无效
Docker 或 Podman 容器中，ulimit -u 设置会被 cgroup 覆盖，根本不起作用。必须用容器运行时参数：
- Docker：
docker run --pids-limit 100 ... - Podman：
podman run --pids-limit=100 ... - 容器内即使以 root 身份运行，也无法突破宿主机设定的 pids cgroup 限额
- systemd 管理的服务（如 nginx、mysql）也不读
limits.conf，得走LimitNPROC=单元配置
实际生效链条很短：PAM 加载 → limits.conf 解析 → 登录时设硬限 → fork() 系统调用失败。漏掉任何一环，比如忘了加 hard、没启 pam_limits.so、或在容器里白忙活，都会让限制形同虚设。
