New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tokio::process::Command leaves zombies when child future is dropped #2685
Comments
Does this playground show the behavior that you're expecting? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2fb1919dae4c46a305d328cb333cd79c You might need to |
No actually the problem is that after the child in the first task is dropped, the child process is killed but waitpid is never called for the first spawned child. Only when there is another command spawned and its future is polled, waitpid is called again You can verify this by removing the second command spawning and waiting eg. on an input. You can now see that the child process is a zombie |
Hi @flumm thanks for the report! It is is a known limitation that we do not call Tokio will perform a best-effort attempt to clean up zombie processes; if no more processes are spawned via tokio, then it is possible some of the processes remain as zombies. One possible work around is to avoid dropping |
hmm... ok so this is 'known' behaviour it probably would be good to somehow extract a handle to to kill it, like mentioned in #2512 |
Version
Platform
Linux zita 5.4.44-2-pve #1 SMP PVE 5.4.44-2 (Wed, 01 Jul 2020 16:37:57 +0200) x86_64 GNU/Linux
Description
when i start a child process with 'kill_on_drop(true)'
and before the future is finished i drop it, there is a zombie
left until a new Child future is polled.
short reproducer: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6746973d696b5122bc212e4bf6436092
i commented out the stdin code for the playground
when run locally it is easier to see that there is a defunct process when looking at e.g., 'ps ax | grep sleep' output
as long as no new child future is polled
i would expect that someone (e.g. the drop handler?) polls the future once again
so that the reaper can call waitpid once more...
The text was updated successfully, but these errors were encountered: