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

PPID is not necessarily 1 when parent frontend is killed #517

Closed
xuesoso opened this issue Jun 18, 2020 · 1 comment · Fixed by #1271
Closed

PPID is not necessarily 1 when parent frontend is killed #517

xuesoso opened this issue Jun 18, 2020 · 1 comment · Fixed by #1271

Comments

@xuesoso
Copy link

xuesoso commented Jun 18, 2020

Hi, I have raised this issue separately on jupyter-console

The problem I noticed is that when I directly close the frontend program that called "jupyter-console" (e.g. my terminal), it leaves the "ipykernel_launcher" running in the background. What I expected to happen is that the kernel session created by "jupyter-console" will be killed whenever its host frontend program is killed. I think I have some clues as to the reason why.

First to provide some of the relevant observations:

  1. On a remote machine without interactive login session, killing the parent frontend (e.g. a Tmux session or terminal) hosting the Jupyter console will lead to the expected killing of ipykernel on the background.
  2. On another machine running Manjaro Gnome, killing the parent frontend (e.g. a Tmux session or terminal) will not kill the ipykernel subprocess. I can see that it's still dangling in the background.

Chasing down the rabbit hole, I found additional observations:

  1. "ipykernel/parentpoller.py" : is responsible for continuous monitoring of parent process that spawned ipykernel. "Line 36" makes the assumption that if the parent of orphaned process is killed, its ID gets set to "1", in which case the kernel will exit itself.
    parentpoller_relevant_code
  2. After adding in a line to log the parent process ID, I found that on the Manjaro Gnome machine, the initial parent process ID transfers from the "jupyer-console":
    initial_ppid
    after killing the initial parent process to:
    post_parent_killed_ppid

ppid

A few additional posts suggest that the parent ID of orphaned processes may not be necessarily set to 1 if there are ancestor processes. Since Gnome 3.34 (and maybe a few more other distributions), there is a shift towards handing off more processes to systemd. Thus when orphaned child arises, it does not get handed off to "init" with a PID of 1. It seems ipykernel may require a special handling to prevent undead backends that consume system resources. A suggestion would be to kill the ipykernel whenever PPID == 1 or PPID == "that of systemd".

@bluss
Copy link
Contributor

bluss commented Oct 1, 2024

I noticed this after having used/adapted the same code into my project (by necessity, I discovered).

jupyter-client already sets JPY_PARENT_PID in the environment when launching the kernel, I'm wondering why it's not using that. Thus the parent pid is known, and could be used for comparison. There can of course always be some obscure reason, that it doesn't work on some platform.

(Alternatively, is it viable to monitor the parent pid and take action if it changes, i.e current process was reparented?)

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

Successfully merging a pull request may close this issue.

2 participants