Title: Python becoming orphaned over ssh
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.1, Python 2.6
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: exarkun, gregory.p.smith, wizzardx
Priority: normal Keywords:

Created on 2010-09-30 07:01 by wizzardx, last changed 2010-09-30 16:19 by gregory.p.smith. This issue is now closed.

Messages (4)
msg117700 - (view) Author: David (wizzardx) Date: 2010-09-30 07:01
Hi, I mentioned this on the mailing list over here:

I think it's a Python bug, so reposting it here:

Hi there, I have a strange situation.

If I do this:

1. Make a script /tmp/ on a remote server, with this contents:

from subprocess import check_call
check_call(['ping', ''])

2. Call the script like this over SSH:

ssh root at testbox /tmp/

3. Interrupt the script with Ctrl+C.

Then what happens:

The SSH session terminates, as expected.


On the testing box, the Python script is still running, and so is the
ping session.

However, if I make an equivalent shell script, /tmp/, with this contents:


And then run it over ssh like this:

ssh root at testbox /tmp/

And then hit Ctrl+C, then the shell script and ping are both
interrupted remotely, as expected.

Here is how 'pstree -p' looks for the python script on the test box,
before Ctrl+C:

<init (1) up here>
│            └─sshd(20233)───bash(20269)───pstree(19875)

And after Ctrl+C:

<init (1) up here>

Basically, the server-side sshd sub-process has disconnected, but the
Python script (and it's ping subprocess) have become orphaned, and now
belong to the init process.

Note, this only seems to happen if Python is executing a subprocess,
and only while Python is being run through a non-interactive ssh

How can I make Python behave better? I want it to close down itself
and it's subprocess, and not orphan itself when I hit ctrl+C


The Python version on the testing box: 2.6.4, and the box itself is
running Ubuntu Karmic. Also, it's not just ping, but other utilities,
eg wget.


I did also try adding logic to the python script, to keep an eye on
all the ppids (parent, grandparent, etc), and then to interrupt itself
and kill it's subprocess, but that doesn't seem to work: For whatever
reason, Python seems to be unable to kill it's subprocess in this
situation. The Python process closes, and ping becomes a child of
init. But I can then kill ping manually, from a separate ssh session.

I've seen this in both Python 2.6 and Python 3.1.
msg117748 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2010-09-30 16:12
can i have you do another experiment here?

after you "ssh root@testbox /tmp/test.{py,sh}" can you:

1) login to testbox, run pstree -p
2) run an strace -p pid_of_python_or_bash >strace_for_foo.out  (for each of the and processes)
3) interrupt both scripts with Ctrl-C
4) repeat the above 1..3 using a that is simply a while True: time.sleep(1) loop.

and attach the strace output for each here?

I'm looking for differences in what happens with signals delivered and processed by each.
msg117749 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2010-09-30 16:14
msg117750 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2010-09-30 16:19
Ah right, thanks.  I added a restore_signals=True argument to Popen in Python 3.2's subprocess module that does what you want:

The way to emulate that in earlier versions is to use a preexec_fn to restore the signal handler for SIGPIPE to SIGDFL.

You can also use backport of 3.2's subprocess module available here:
Date User Action Args
2010-09-30 16:19:32gregory.p.smithsetstatus: open -> closed
resolution: wont fix
messages: + msg117750
2010-09-30 16:14:55exarkunsetnosy: + exarkun
messages: + msg117749
2010-09-30 16:12:29gregory.p.smithsetmessages: + msg117748
2010-09-30 13:21:33pitrousetnosy: + gregory.p.smith
2010-09-30 07:01:34wizzardxcreate