python and ssh

Discussion in 'Python' started by Jim, Jul 22, 2004.

  1. Jim

    Jim Guest

    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,
     
    Jim, Jul 22, 2004
    #1
    1. Advertising

  2. Jim

    Guest

    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
     
    , Jul 22, 2004
    #2
    1. Advertising

  3. On Wed, 21 Jul 2004 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.close()
    sys.stderr.close()

    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!)
     
    Christopher T King, Jul 22, 2004
    #3
  4. Jim

    G. S. Hayes Guest

    wrote in message news:<>...
    > 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
     
    G. S. Hayes, Jul 22, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. loial
    Replies:
    0
    Views:
    405
    loial
    Feb 3, 2009
  2. loial
    Replies:
    0
    Views:
    406
    loial
    Feb 10, 2009
  3. Tench Johnson
    Replies:
    1
    Views:
    294
    Biff Tannen
    Apr 23, 2010
  4. Deepika
    Replies:
    2
    Views:
    213
    Deepika
    Nov 14, 2006
  5. Replies:
    0
    Views:
    106
Loading...

Share This Page