真正防止 fork 炸弹需分层设置：用户级（limits.conf）、系统级（pid_max）、服务级（systemd LimitNPROC/TasksMax），三层缺一不可，否则限制无效或无法生效。
直接用 ulimit -u 扩容单用户最大进程数，只能临时缓解 fork 炸弹风险，但无法真正防住——因为该命令只作用于当前 shell 及其子进程，退出或新登录即失效，且不约束 systemd 服务、SSH 登录会话或 root 用户行为。要真正防止 fork 炸弹触发 “Resource temporarily unavailable”，必须分层设置：用户级限制 + 系统级兜底 + 服务级加固。
确认当前限制并识别瓶颈
先查清哪一层卡住了：
- 当前 shell 的用户进程上限：
ulimit -u - 系统全局 PID 上限（硬天花板）：
cat /proc/sys/kernel/pid_max，若 ≤ 32768，多数应用已接近临界 - 当前用户实际可用值（受 PAM 限制）：
prlimit -n $BASHPID | grep "NPROC" - root 是否被特殊豁免：
grep -r "nproc" /etc/security/limits.d/，常见如20-nproc.conf里设了root soft nproc unlimited，而普通用户却被锁在 4096
永久生效的用户级扩容（针对普通用户和 SSH 登录）
编辑 /etc/security/limits.conf，**必须分开写 root 和普通用户两行**，不能只靠 *：
root soft nproc 65535root hard nproc 65535* soft nproc 65535* hard nproc 65535
⚠️ 注意：hard 必须 ≥ soft；改完需完全退出并重新登录（仅 source 或重启 sshd 不生效）；图形界面用户要注销整个会话。
绕过 limits.conf 失效场景：systemd 服务专用配置
Java 应用、Redis、Nginx 等通过 systemd 启动的服务完全不读取 limits.conf，必须单独配置：
- 编辑服务文件，如
/etc/systemd/system/myapp.service - 在
[Service]段添加：LimitNPROC=65535TasksMax=65535（systemd 240+ 推荐配此项防任务溢出） - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart myapp
内核级兜底：调高 pid_max 防止全局耗尽
即使每个用户都设了 65535，若 kernel.pid_max 还是默认 32768，所有用户加起来一碰就满：
- 临时生效：
sudo sysctl -w kernel.pid_max=4194304 - 永久生效：写入
/etc/sysctl.d/99-pidmax.conf：kernel.pid_max = 4194304
再执行sudo sysctl --system - 验证：
cat /proc/sys/kernel/pid_max，确保 ≥ 单用户上限 × 并发用户数
真正防 fork 炸弹，不是堆高数字，而是让限制“可感知、可拦截、不越界”。三层齐设后，异常进程会在 fork 阶段直接失败，不会拖垮 SSH 或系统响应。
