spawnv( ) or spawnl( ) do not launch a normal running process in Python 2.2.2?

[nushin]

Try to launch a test program that prints hello world for a minute or
so using, spawnv( ) or spawnl( ). Check to see the process state code
that the program is running. I am using RedHat Linux 7.3 and Python
2.2.2 and i see that the program is either launched as Zombie state
using spawnv(), or running in State "S" sleep in spawnl( ).

Here's the sample code that launches my program:

os.spawnv(os.P_NOWAIT,'/usr/bin/python',('python hello.py >/dev/null
&'))
os.spawnl(os.P_NOWAIT,'/usr/bin/python',('python hello.py >/dev/null
&'))

When you launch a program in Linux, you want it to run in state "R" ,
a running state. Am i the only one who has this problem? Would the
author of spawnv(), spawnl() look into this problem please.

Regards,
Nushin

[Patrick Useldinger]

nushin wrote:

os.spawnv(os.P_NOWAIT,'/usr/bin/python',('python hello.py >/dev/null
&'))
os.spawnl(os.P_NOWAIT,'/usr/bin/python',('python hello.py >/dev/null
&'))

Did you try *without* the redirections?

--
Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
Visit my Homepage at http://www.homepages.lu/pu/

[Jeff Epler]

the third argument to os.spawnv is an argument list as in execv, not a
command string as in popen and system. The statement you listed

os.spawnv(os.P_NOWAIT,'/usr/bin/python',('python hello.py >/dev/null

runs the Python binary with its argv[0] set to 'python hello.py >/dev/null',
which is probably going to drop into trying to read a script from
standard input since there is no script or command on the commandline,
but I'm not really sure what to expect in this crazy case.

There's no easy way to do command redirections while using spawnv.
Here's a piece of code to do so with fork+exec [tested]:
def F(x):
if not isinstance(x, int): return x.fileno()

def coroutine(args, child_stdin, child_stdout, child_stderr):
pid = os.fork()
if pid == 0:
os.dup2(F(child_stdin), 0)
os.dup2(F(child_stdout), 1)
os.dup2(F(child_stderr), 2)
os.execvp(args[0], args)
return pid
you could do something similar with os.spawnv [untested]:
def dup2_noerror(a, b):
try:
os.dup2(a, b)
except:
pass

def coroutine_spawnv(flags, args, child_stdin, child_stdout, child_stderr):
old_stdin = os.dup(0)
old_stdout = os.dup(1)
old_stderr = os.dup(2)
try:
os.dup2(F(child_stdin), 0)
os.dup2(F(child_stdout), 1)
os.dup2(F(child_stderr), 2)
return os.spawnv(flags, args[0], args)
finally:
dup2_noerror(old_stdin, 0)
dup2_noerror(old_stdout, 1)
dup2_noerror(old_stderr, 2)

Jeff

[nushin]

Thanks Jeff. Yes, i think it's the stdio buffering that causes
P_NOWAIT act asif it's a P_WAIT. I wish an additional parameter could
be added to spawnv( ) to toggle its stdout on/off.

Regards,
Nushin

Jeff Epler <je****@unpythonic.net> wrote in message news:<ma**********************************@python. org>...

I don't see any problem with P_NOWAIT. Take the following for example:

$ cat nushin.py
import os

p = os.spawnvp(os.P_NOWAIT, 'sh',
['sh', '-c', 'sleep 1; echo from spawnv'])
print "from program"
print "waitpid returns:", os.waitpid(p, 0)
$ python -u nushin.py
from program
waitpid returns:from spawnv
(2826, 0)

Now, if the program completed very quickly, it's a coin-flip whether its
output would appear before "from program". In this case, I made sure
the program would take a really long time (1 second) to complete.

When running without -u but not on a terminal, you might see
$ python nushin.py | cat
from spawnv
from program
waitpid returns: (2832, 0)
.. this is because the Python process has printed "from program", but
stdio buffering has kept it from actually being written to the output
yet.

Here's what you see on a terminal without -u:
$ python nushin.py
from program
from spawnv
waitpid returns: (2835, 0)
This is the same thing you'd see if the program said
print "from program"; sys.stdout.flush()

Jeff