🐛 Bug: Turbo daemon creates / leaves a ton of <defunct>
processes, accumulating enough sometimes to breach the OS-wide process limit, preventing the creation of any new processes.
#9455
Labels
kind: bug
Something isn't working
Verify canary release
Link to code that reproduces this issue
I think: all turbo projects running turbo while in interactive-rebase.
This is a pretty bad bug, because MacOS only has a limit of ~ 5600 processes, and once you hit that, you can't spawn terminals, can't open apps, can't create new tabs in the browser, can't run
ps
, even.You have to have already had activity monitor (or similar) open so that you can kill the
turbo
daemon process. Else you may be forced to reboot.Which canary version will you have in your reproduction?
2.3.1-canary.0
Enviroment information
Setup, check processes:
Normally, an OS should be around < 1000 processes:
Scenario A (inconsistent)
(I'm splitting commits into more commits)
Scenario B (inconsistent)
Test:
Test after upgrading to latest canary (noting that we run
build
in postinstall):I have an ongoing monitor for this running every second in a terminal that I just leave up all the time.
❯ watch -n 1 "echo \"All: \$(ps -ef | wc -l), Defunct: \$(ps -ef | grep defunct | wc -l)\""
And with pstree we can see that these all come from turbo
Which will print something like this:
Expected behavior
no defunct processes exist ever, as the OS will not halt these.
Actual behavior
defunct processes are left laying around.
To Reproduce
It's possible this is reproducible in these OSS repos:
I somewhat regularly have to kill the top level
turbo
daemon on Linux due to CPU usage -- but it's maybe possible that the reason for that is the same root reason that is causing me to observe the behavior that has resulted in me reporting this issue for MacOS.In both cases, Linux (where I do most of my OSS) and Mac (where I do my closed-source employer-owned work), Killing the turbo daemon processes immediately makes any of my machines happier -- cleaning up defunct processes (macos) or freeing up cpu cycles (linux)
Additional context
No response
The text was updated successfully, but these errors were encountered: