最有效、最易落地的防fork炸弹手段是限制单个用户最大进程数，核心为ulimit -u控制nproc，需配齐软硬限制并确保PAM加载pam_limits.so模块生效。
直接限制单个用户最大进程数，是防 fork 炸弹最有效、最易落地的手段。核心就一条：ulimit -u 控制 nproc，软硬限制必须配齐，且需确保 PAM 加载生效。
ulimit -u 临时限制只对当前 shell 会话生效
运行 ulimit -u 100 后，该终端里任何新进程（包括子 shell、脚本、:(){:|:&};:）一旦超过 100 个，fork() 就会失败并返回 EAGAIN，fork 炸弹当场卡死。但这个设置不会继承到新登录会话，也不影响其他终端或 SSH 连接。
- 验证是否生效：执行
ulimit -u查看当前值；再跑seq 1 150 | xargs -P 150 sleep 0.1 &，会报Resource temporarily unavailable - 注意：root 用户默认不受普通用户的
ulimit限制影响，sudo -u otheruser ulimit -u 50才能模拟目标用户环境 - 别依赖它做长期防护——登出重登就失效，仅适合测试或紧急干预
/etc/security/limits.conf 必须配 soft + hard nproc
要让限制持久化并覆盖所有登录方式（SSH、GUI、su 切换），必须写进 /etc/security/limits.conf，且 soft 和 hard 都得设。只写 soft 没用，因为用户可自行调高（只要不超 hard）；只写 hard 则初始值仍是系统默认（通常是 1024 或更高），起不到压制作用。
- 正确写法示例：
alice soft nproc 200和alice hard nproc 200（两行） - 对组生效：用
@developers soft nproc 300，但注意 root 不受组限制 - 通配符
*要慎用——* soft nproc 512会影响所有非 root 用户，包括系统服务账户，可能引发 cron、systemd-user 等异常 - 改完必须重新登录才生效；
su - alice可验证，然后ulimit -u确认数值
PAM 模块 session required pam_limits.so 是前提
没有这行，limits.conf 就是废纸。几乎所有主流发行版默认已启用，但定制系统或容器镜像常被删掉。
- 检查命令：
grep pam_limits.so /etc/pam.d/{login,sshd,su,system-auth} - 缺失时，在
/etc/pam.d/sshd（SSH 登录）或/etc/pam.d/system-auth（通用）中添加：session required pam_limits.so - 注意路径：CentOS/RHEL 用
/lib64/security/pam_limits.so，Debian/Ubuntu 用/lib/x86_64-linux-gnu/security/pam_limits.so，写错路径会导致 PAM 加载失败且无明显报错 - 修改后无需重启 sshd，新连接即生效；旧连接仍按原限制运行
容器环境要用 --pids-limit，ulimit 不起作用
Docker 或 Podman 容器里，ulimit 设置会被 cgroup v2 的 pids.max 覆盖。即使你在容器内执行 ulimit -u 1000，只要宿主机用 --pids-limit=100 启动，实际 fork 上限就是 100。
- 启动容器时加参数：
docker run --pids-limit=100 ubuntu:24.04 - 对应 cgroup 文件是
/sys/fs/cgroup/pids/.../pids.max，值为100表示最多 100 个进程（含线程） - 容器内
ulimit -u显示的仍是宿主机传入的默认值（如 1048576），别被它骗了——真正起作用的是pids.max - Kubernetes 中通过
securityContext.pidsLimit设置，低于 1.20 版本不支持，需确认集群版本
真正容易被忽略的点是：限制值不能拍脑袋定。设太低（比如 nproc 20）会让正常用户连 tmux、多个 vim 实例都打不开；设太高（比如 10000）又失去防护意义。建议从 ps -U $USER --no-headers | wc -l 统计日常峰值，再上浮 30%～50% 作为 hard 限制。另外，root 始终豁免，所以管理账户安全本身不能只靠这一层。
