By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,959 Members | 1,196 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,959 IT Pros & Developers. It's quick & easy.

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

P: n/a
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 >/dev/null
os.spawnl(os.P_NOWAIT,'/usr/bin/python',('python >/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.

Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies

P: n/a
nushin wrote:
os.spawnv(os.P_NOWAIT,'/usr/bin/python',('python >/dev/null
os.spawnl(os.P_NOWAIT,'/usr/bin/python',('python >/dev/null

Did you try *without* the redirections?

Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
Visit my Homepage at

Jul 18 '05 #2

P: n/a
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 >/dev/null

runs the Python binary with its argv[0] set to 'python >/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):
os.dup2(a, b)

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)
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)
dup2_noerror(old_stdin, 0)
dup2_noerror(old_stdout, 1)
dup2_noerror(old_stderr, 2)


Jul 18 '05 #3

P: n/a
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.


Jeff Epler <je****> wrote in message news:<ma**********************************@python. org>...
I don't see any problem with P_NOWAIT. Take the following for example:

$ cat
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
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 | 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

Here's what you see on a terminal without -u:
$ python
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()


Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.