python and ssh

[G. S. Hayes]

jepler at unpythonic.net wrote in message news:<mailman.692.1090462331.5135.python-list at 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.programmer 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