登录VPS后，Bash不断提示fork: Resource temporarily unavailable，连ps都可能无法启动。此时Shell仍在运行，但系统拒绝创建新的进程或线程。
不要把它等同于内存不足，fork返回EAGAIN更常见于进程数量限制。
哪些限制会让fork失败
Linux fork(2)文档列出多种EAGAIN来源，包括用户的RLIMIT_NPROC、系统threads-max、PID空间上限以及cgroup的pids.max。容器和systemd服务还可能受到父级cgroup限制。
最严格的那一级限制生效，只调大某一个数值不一定恢复。
命令都跑不了时怎样自救
优先保留现有SSH会话，不要反复新开连接。Bash内建的ulimit -u不需要启动外部进程，可先读取用户上限；必要时使用Shell内建循环检查/proc，或通过已有管理控制台进入。
不要立即重启整台服务器。先确认是否有失控服务、fork炸弹或线程泄漏，避免重启后再次耗尽。
核对用户与cgroup进程数
系统恢复少量执行能力后，用ps -eLf观察线程总量和异常进程树，并检查目标服务的TasksCurrent、TasksMax。cgroup v2环境读取对应目录的pids.current、pids.max和事件计数。
线程也会计入相关进程限制。仅统计进程主PID可能低估实际使用量。
先止损再调整上限
识别失控进程后先优雅停止服务，必要时在确认PID归属后终止进程。只有正常负载确实需要更多任务时，才调整用户限制、systemd的TasksMax=或容器PID配额。
无限放大上限会削弱故障隔离。应同时修复循环拉起、线程泄漏或不受控并发，并保留容量余量。
恢复后的验收方法
确认可以持续启动新命令，异常任务数下降，服务重启后pids.current不再贴近上限。可在萤光云或LightNode的隔离VPS模拟小型PID配额。验收标准是交互Shell恢复、关键服务稳定、限制仍能保护主机且监控会在接近阈值时告警。
FAQ
问：free显示内存充足，为什么仍不能fork？答：EAGAIN可由进程或PID限制触发，与可用内存充足并不矛盾。
问：root一定不受影响吗？答：root可绕过部分用户资源限制，但仍可能受到系统PID、线程或cgroup层级限制。
温馨提示
温馨提示：为Web服务、队列和容器设置合理的任务数上限，并监控线程数、pids.current与失败事件。容量调整要和应用并发模型一起评估。
