debugging os.spawn*() calls

Donn Cave donn at u.washington.edu
Thu Feb 3 14:54:47 EST 2005


In article <mailman.1515.1106926549.22381.python-list at python.org>,
 Martin Franklin <mfranklin1 at gatwick.westerngeco.slb.com> wrote:

> Skip Montanaro wrote:
> > I have an os.spawnv call that's failing:
> > 
> >     pid = os.spawnv(os.P_NOWAIT, "ssh",
> >                     ["ssh", remote,
> >                      "PATH=%(path)s nice -20 make -C %(pwd)s" % locals()])
> > 
> > When I wait for it the status returned is 32512, indicating an exit status
> > of 127.  Unfortunately, I see no way to collect stdout or stderr from the
> > spawned process, so I can't tell what's going wrong.
> > 
> > The "ssh remotehost PATH=$PATH nice -20 make ..." command works fine from a
> > similar shell script.
...
> While not a 'real' answer - I use pexpect to automate my ssh scripts 
> these days as I had a few problems using ssh with the os.* family 
> perhaps you may find pexpect a wee bit easier...

Also, a "-n" can also improve reliability.  By default,
ssh assumes that you meant to copy data as input to the
remote command, and it does so if it can.  Very likely
at the expense of some other process that you expected
would be able to read that data later.  -n informs ssh
that you don't intend to provide any data to the remote
command.

But that's probably not the present problem.  (Not that
it's really all that "present" by now!)  127 seems to
mean that the "ssh" command couldn't be found or couldn't
be executed.

I guess if something like that were really getting me
down, I might rewrite os._spawnvef with a pipe.  On
entering the except clause I'd format the exception
and write it to the pipe;  otherwise, I'd just close
the pipe.  The parent could then read the pipe, even
for a NOWAIT case like this, and possibly contrive to
re-raise the fork's exception if one showed up.  This
would account for the class of errors that occurs between
the fork and the exec.  The _spawnvef I'm looking at
doesn't account for these very well - 127 covers a lot
of ground, and there wouldn't be much in the way of
error output.

   Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list