-
Notifications
You must be signed in to change notification settings - Fork 81
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
Launching player from trackma leaves zombie process on linux. #508
Comments
If we ignore SIGCHLD then init(1) automatically reaps child process on exit and this fixes not getting player process close event on polling/inotify trackers. Fixes z411#508
I went with 3rd method because it was easier and cleaner. |
I found a bug which occurs if we ignore SIGCHLD. If parent exits while child is running, child exits too. So I used fork then waitpid; fork again in forked child then os.execv to prevent zombie process without relying on ignoring SIGCHLD. I'll create a new pr with this fix. |
If we ignore SIGCHLD then init(1) automatically reaps child process on exit and this fixes not getting player process close event on polling/inotify trackers. Fixes z411#508
If we ignore SIGCHLD then init(1) automatically reaps child process on exit and this fixes not getting player process close event on polling/inotify trackers. Fixes z411#508
Did some testing and using Popen the zombie process gets reaped within seconds of being closed. Apparently Python 3 should automatically reap zombie processes whenever they get garbage collected. What Python version are you using? Do you get a different behavior? |
I'm using python 3.8.6, on manjaro. By the way... they were never reaped :|. Whenever I tried to reap all zombies with zps, trackma was killed too, even after closing the player a few hours before running zps.
|
Python 3.8.6 here and Arch Linux here. Weird since our configuration is similar, I tried with vlc and it gets reaped after around 5-10 seconds. This must be why I never noticed it. That said I guess we shouldn't have a zombie process in the first place at all, so I'll look into fixing this. |
I tried with the ignore SIGCLD method again (after moving processes out of the engine) and it works perfectly for me. I don't get the bug you described and I don't get a zombie process either. Could you try my |
Player dies as soon as trackma quits if sigchld is ignored.
…On Sat, Nov 21, 2020 at 22:50, z411 ***@***.***> wrote:
I tried with the ignore SIGCLD method again (after moving processes
out of the engine) and it works perfectly for me. I don't get the bug
you described and I don't get a zombie process either. Could you try
my the prevent-zombie branch?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#508 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF5WM3X5366CPYQKCWNOR5DSRCYCRANCNFSM4QME4NKQ>.
|
I seriously can't reproduce this... Could you try with a clean config, and ideally with the tracker disabled? I'll try to find other people to try and see if they can reproduce it. |
Though I Started trackma with XDG_CONFIG_HOME=/tmp/ch
XDG_DATA_HOME=/tmp/dd trackma-gtkand tracker was disabled, Vlc again
closed on its own after closing trackma.
…On Sat, Nov 21, 2020 at 23:28, z411 ***@***.***> wrote:
I seriously can't reproduce this...
<https://streamable.com/3p345m>
Could you try with a clean config, and ideally with the tracker
disabled?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#508 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF5WM3XUN2QNPXOWGP44ECLSRC4RHANCNFSM4QME4NKQ>.
|
Running just I can not reproduce the first case as well
zps -l output is empty. On the Also Arch, btw. |
|
Steps to reproduce
zps -l
Cause
Player was started using
subprocess.Popen()
, but not calling.wait()
or.poll()
onPopen()
ed process leaves a zombie.Possible workarounds: [downsides may be caused by my implementation]
os.execvp
fork()
ed zombie process** fixed after calling os.waitpid on first fork
subprocess.Popen().wait()
in a threadSIGCHLD
The text was updated successfully, but these errors were encountered: