You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
"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.
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":
after killing the initial parent process to:
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".
The text was updated successfully, but these errors were encountered:
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?)
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:
Chasing down the rabbit hole, I found additional observations:
after killing the initial parent process to:
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".
The text was updated successfully, but these errors were encountered: