python and ssh

[Jim]

Hi,

I'm fairly new to python, and unix systems in general.

I have a script where I am trying to launch a remote process. What
I'm doing is something like:

from host machine:
p = popen2.POpen4(' ssh user@remote ssh /home/remote.py cmd arg1 arg2
....' )

so the remote machine has a remote.py script which gets the arguments
that i want to execute.

in the remote.py script, i pretty much just do a
pid = os.spawnv( os.P_NOWAIT, [cmd, cmdname, arg1, arg2, ... ] )
then i exit the script, i also send the pid over a socket before
exiting.

I noticed that even thought the python process dies, ssh still 'knows'
about the spawned process, so the ssh session is still going.

My question is can I rely on this behavior? How did ssh know about
the spawned process?

Thank you,

[jepler]

You would have to ask the authors of ssh that question.

I *suspect* that sshd creates special file descriptors that communicate
with the process started on the remote machine as the user. Then it
enters a select loop. Once all the programs with access to that file
descriptor close it (for instance, by exiting), sshd detects this because
the file descriptors are "readable" according to select, but a read gets
0 bytes. When that happens, sshd closes down communication with ssh,
which exits.

Jeff

[Christopher T King]

On Wed, 21 Jul 2004 je****@unpython ic.net wrote:

You would have to ask the authors of ssh that question.

I *suspect* that sshd creates special file descriptors that communicate
with the process started on the remote machine as the user. Then it
enters a select loop. Once all the programs with access to that file
descriptor close it (for instance, by exiting), sshd detects this because
the file descriptors are "readable" according to select, but a read gets
0 bytes. When that happens, sshd closes down communication with ssh,
which exits.

Building off of that, in order to get ssh to end the connection, the
spawned process will need to close the descriptors it inherited from
ssh:

import sys
sys.stdin.close ()
sys.stdout.clos e()
sys.stderr.clos e()

Basically, ssh is staying open because it knows that it's possible for the
spawned process to write to these streams, which would normally be
redirected over the ssh connection. By closing them, you're telling ssh
"I don't need to do any more input or output to/from the console", and ssh
(should) respond to this by closing the connection. (I say should because
I haven't tested this!)

[G. S. Hayes]

je****@unpython ic.net wrote in message news:<ma******* *************** *************** @python.org>...

You would have to ask the authors of ssh that question.

I *suspect* that sshd creates special file descriptors that communicate
with the process started on the remote machine as the user. Then it
enters a select loop. Once all the programs with access to that file
descriptor close it (for instance, by exiting), sshd detects this because
the file descriptors are "readable" according to select, but a read gets
0 bytes. When that happens, sshd closes down communication with ssh,
which exits.

(You may be able to get away with a shell script that nohups your
python script, possibly disown'ing it as well)

If you're running under some flavor of Unix, it's also likely that ssh
has created a pty as a controlling terminal for your process group, in
which case you'll need to jump through a couple more hoops (setsid,
etc). The comp.unix.progr ammer FAQ has a section "How do I get my
program to act like a daemon?" which explains the steps required to
make this work:
http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16
It's written for C, but there are Python wrappers for all the relevant
syscalls (mostly in the os module)

If it is just the file descriptors, you probably want to close stdout
and stderr (and probably stdin) before launching the new process. You
want to replace them with new values (often /dev/null is handy here).
Best way to do this is to switch from os.spawnv to os.fork and
os.execv, and do the process setup for the new process in between
those two calls--but if you're on Windows that's not an option; if
you're planning on exiting immediately anyway, you may get away with
doing it in the main process before the spawnv call.

Sumner