Skip to content
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

Open
ahmubashshir opened this issue Aug 26, 2020 · 12 comments · Fixed by #512
Open

Launching player from trackma leaves zombie process on linux. #508

ahmubashshir opened this issue Aug 26, 2020 · 12 comments · Fixed by #512

Comments

@ahmubashshir
Copy link
Contributor

ahmubashshir commented Aug 26, 2020

Steps to reproduce

  • Open trackma.
  • Play something.
  • Close player.
  • Check for zombie process with zps -l
sh-5.0$ zps -l
PID   	PPID  	STATE	            NAME COMMAND
4097215	4088507	Z 	             vlc 
sh-5.0$ ps -p 4088507
    PID TTY          TIME CMD
4088507 pts/3    00:00:01 trackma-gtk

Cause

Player was started using subprocess.Popen(), but not calling .wait() or .poll() on Popen()ed process leaves a zombie.

Possible workarounds: [downsides may be caused by my implementation]
  • Double fork then os.execvp
    • Upside: launches the player as a child of init, so it is reaped as soon as the process ends.
    • Downside: leaves a fork()ed zombie process*
      * fixed after calling os.waitpid on first fork
  • subprocess.Popen().wait() in a thread
    • Upside: After launching, the thread waits for the child to terminate, then reaps the child.
    • Downside: Can't Close the UI unless palyer is closed too.
  • Ignore SIGCHLD
ahmubashshir added a commit to ahm-forks/trackma that referenced this issue Oct 14, 2020
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
@ahmubashshir
Copy link
Contributor Author

I went with 3rd method because it was easier and cleaner.

@z411 z411 closed this as completed in #512 Oct 15, 2020
@ahmubashshir
Copy link
Contributor Author

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.

ahmubashshir added a commit to ahm-forks/trackma that referenced this issue Oct 17, 2020
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
ahmubashshir added a commit to ahm-forks/trackma that referenced this issue Oct 30, 2020
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
@z411 z411 reopened this Nov 21, 2020
@z411
Copy link
Owner

z411 commented Nov 21, 2020

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?

@ahmubashshir
Copy link
Contributor Author

ahmubashshir commented Nov 21, 2020

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.
And from this issue, subprocess only reaps previous process on new Popen

image
On afeaef7 after closing vlc [closed on 01:22].

@z411
Copy link
Owner

z411 commented Nov 22, 2020

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.

@z411
Copy link
Owner

z411 commented Nov 22, 2020

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 prevent-zombie branch?

@ahmubashshir
Copy link
Contributor Author

ahmubashshir commented Nov 22, 2020 via email

@ahmubashshir
Copy link
Contributor Author

1
Peek 2020-11-22 13-05

@z411
Copy link
Owner

z411 commented Nov 22, 2020

I seriously can't reproduce this...

https://streamable.com/3p345m

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.

@ahmubashshir
Copy link
Contributor Author

ahmubashshir commented Nov 22, 2020 via email

@FichteFoll
Copy link
Collaborator

Running just python -m trackma.ui.cli play 2 should be enough to reproduce the second case, right? Because that simply opens mpv for me and does not kill it.

I can not reproduce the first case as well

Open trackma.
Play something.
Close player.
Check for zombie process with zps -l

zps -l output is empty. On the prevent-zombie branch ofc, since I can't play anything on master due to #525.

Also Arch, btw.

@ahmubashshir
Copy link
Contributor Author

Running just python -m trackma.ui.cli play 2 should be enough to reproduce the second case, right? Because that simply opens mpv for me and does not kill it.

I can not reproduce the first case as well

Open trackma.
Play something.
Close player.
Check for zombie process with zps -l

zps -l output is empty. On the prevent-zombie branch ofc, since I can't play anything on master due to #525.

Also Arch, btw.

python -m trackma.ui.cli play 2 quits after launching player, doesn't it? so child process is reparented to init(1) that's why zps -l is empty :3
btw... I confirmed now... This only happens in Gtk UI. https://streamable.com/l887xl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants