iTerm提示unable to fork, too many processes？求问题根源及排查方法

我之前也碰到过一模一样的问题——Activity Monitor看起来进程数完全正常，但iTerm就是死活开不了新窗口，弹出那个烦人的“unable to fork, too many processes”提示。重启确实能快速解决，但要搞清楚背后的原因，下次遇到就能不用重启直接搞定，给你梳理一下我总结的思路：

可能的原因 #

• 用户进程数配额耗尽：Mac系统默认给每个用户设置了进程数上限，虽然Activity Monitor显示的总进程数不多，但你当前用户名下的进程可能已经触顶了。很多后台小进程（比如定时脚本、应用的辅助服务）不会在“应用程序”标签里显示，却悄悄占着配额。
• iTerm自身进程泄漏：iTerm偶尔会有bug，导致后台生成大量隐藏的子进程（比如com.googlecode.iterm2.agent这类辅助进程），这些进程在Activity Monitor的“应用程序”标签里看不到，得切换到“进程”标签才能发现。
• 系统内核资源耗尽：有时候不是进程数量的问题，而是内核级的资源（比如进程表条目、文件描述符）被用光了，这时候哪怕总进程数看起来正常，fork新进程也会失败。

具体排查方法 #

• 检查用户进程数上限与实际使用量：
  如果还能打开其他终端（比如系统自带的Terminal.app），执行这两个命令：
  • 查看当前用户的进程数上限：ulimit -u
  • 统计当前用户的实际进程数：ps -u $(whoami) | wc -l
    要是实际数接近或等于上限，那就是配额的问题了。
• 揪出iTerm的隐藏进程：
  执行ps aux | grep iTerm，看看是不是有一堆重复的iTerm相关进程。如果发现大量类似com.googlecode.iterm2.agent的进程，那就是iTerm的进程泄漏了，手动kill掉这些进程（kill -9 [进程ID]）就能临时解决，最好顺便把iTerm更到最新版本修复bug。
• 检查系统级进程资源：
  用sysctl kern.maxproc kern.maxprocperuid查看系统总进程上限和单用户上限，再用sysctl kern.proc_count看当前系统总进程数。如果总进程数快到上限了，就得找哪个进程在疯狂创建子进程。
• 翻系统日志找线索：
  打开“控制台”应用，搜索“fork failed”或者“too many processes”，系统日志里会有更详细的错误信息，比如指出是哪个进程导致的资源耗尽，或者是哪种内核资源不够用。

临时修复与长期预防 #

• 要是ulimit不够用，可以临时调高：ulimit -u 2048（数值可以根据自己的需求调整），不过重启后会失效。想永久生效的话，就在~/.zshrc或者~/.bashrc（看你用的shell）里加一行ulimit -u 2048。
• 定期更新iTerm到最新版，官方一直在修复这类进程泄漏的bug。
• 要是查到是某个第三方应用在乱生成进程，果断更新或者卸载它，从根源解决问题。

内容的提问来源于stack exchange，提问作者Travelholics