Killing children

[Laura Conrad]

I'm writing an application that has to spawn some processes and then
kill them later. It doesn't need to talk or listen to them while
they're running, but there are stop and start buttons and the stop
button should stop everything that gets started by the start button.

There are lots of ways to do this on Linux, but this project has to
run under cygwin. So far, the only thing I've gotten to work at all
under cygwin is doing an 'os.system' to start the process and then
parsing the "ps" output and using os.kill on the processes that ps
finds. This is unsatisfactory in a number of ways.

I have been unable to get os.spawnl to start the processes correctly.
I was using pexpect, which worked fine with test programs, but not
with the actual processes that need to be spawned. I did a little bit
of playing with the "process" module but didn't get it working right.

Does anyone have a better idea?

 

[Peter Hansen]

I'm writing an application that has to spawn some processes and then
kill them later. It doesn't need to talk or listen to them while
they're running, but there are stop and start buttons and the stop
button should stop everything that gets started by the start button.

There are lots of ways to do this on Linux, but this project has to
run under cygwin. So far, the only thing I've gotten to work at all
under cygwin is doing an 'os.system' to start the process and then
parsing the "ps" output and using os.kill on the processes that ps
finds. This is unsatisfactory in a number of ways.

I have been unable to get os.spawnl to start the processes correctly.
I was using pexpect, which worked fine with test programs, but not
with the actual processes that need to be spawned. I did a little bit
of playing with the "process" module but didn't get it working right.

Does anyone have a better idea?

This has been successful in some cases:

if sys.platform == 'win32':
def _kill(pid, sig):
'''pid is actually handle, but that's what os.spawn* returns on
Win32'''
import win32api
win32api.TerminateProcess(pid, 0) # ignore sig, 0 is return
code for process
import os
os.kill = _kill
del _kill


It requires win32api, and I don't know how that all will work with
cygwin (which I don't use). Basically it lets you use os.kill()
in a platform-independent fashion (provided you care only about
Linux and Windows NT/XP/2K ;-).

-Peter

 

[Stefan Eischet]

Hi Laura,

what a terrible subject line! ;-)

I sometimes use os.system with pskill from
http://www.sysinternals.com/ntw2k/freeware/pskill.shtml - this should
do what you want.

I do get my pid from some spawn-variant, IIRC. This should be more
reliable than killing by name or parsing ps output (since you might
kill the wrong process if there are multiple processes with the same
name).

What exactly doesn't work with your spawning? Could you post the spawn
call you're using?

Cheers,
Stefan

I'm writing an application that has to spawn some processes and then
kill them later. It doesn't need to talk or listen to them while
they're running, but there are stop and start buttons and the stop
button should stop everything that gets started by the start button.

There are lots of ways to do this on Linux, but this project has to
run under cygwin. So far, the only thing I've gotten to work at all
under cygwin is doing an 'os.system' to start the process and then
parsing the "ps" output and using os.kill on the processes that ps
finds. This is unsatisfactory in a number of ways.

I have been unable to get os.spawnl to start the processes correctly.
I was using pexpect, which worked fine with test programs, but not
with the actual processes that need to be spawned. I did a little bit
of playing with the "process" module but didn't get it working right.

Does anyone have a better idea?

// (e-mail address removed) //

 

[Laura Conrad]

Peter> on Win32'''
Peter> import win32api

Peter> It requires win32api, and I don't know how that all will work with
Peter> cygwin (which I don't use).

win32api doesn't seem to be there on cygwin.

 

[Peter Hansen]

Peter> on Win32'''
Peter> import win32api

Peter> It requires win32api, and I don't know how that all will work with
Peter> cygwin (which I don't use).

win32api doesn't seem to be there on cygwin.

Nor on regular Python, until you download it. It's in a separate
package, formerly called win32all, now called pywin32...

-Peter

 

[Erik Max Francis]

I used to think that when I first started using UNIX in the mid 80's.
But I am now a hardened child-killer.

I bet you even let them turn into zombies before you kill them! You
animal!

 

[Peter Hansen]

p = os.spawnl(os.P_NOWAIT, "/usr/bin/python", "python", "hobo.py", '/dev/ttyS0', 5)
print p

os.system("ps")
time.sleep(60)
os.system("kill %d" % p)

This suggests that you believe the return value from os.spawnl() is
actually the PID. Unfortunately that doesn't appear to be the case
on Windows. See the note in the doc-string for my code sample from
the previous post (on Windows spawn* actually returns a "handle",
not the PID itself, and apparently turning the one into the other
is non-trivial).

-Peter

 

[Laura Conrad]

Peter> This suggests that you believe the return value from os.spawnl() is
Peter> actually the PID. Unfortunately that doesn't appear to be the case
Peter> on Windows. See the note in the doc-string for my code sample from
Peter> the previous post (on Windows spawn* actually returns a "handle",
Peter> not the PID itself, and apparently turning the one into the other
Peter> is non-trivial).

So you think os.kill(p) might be the way to kill it? But does anyone
know how to get it started right?

 

[Peter Hansen]

Peter> This suggests that you believe the return value from os.spawnl() is
Peter> actually the PID. Unfortunately that doesn't appear to be the case
Peter> on Windows. See the note in the doc-string for my code sample from
Peter> the previous post (on Windows spawn* actually returns a "handle",
Peter> not the PID itself, and apparently turning the one into the other
Peter> is non-trivial).

So you think os.kill(p) might be the way to kill it? But does anyone
know how to get it started right?

Uh... maybe? I think I just got out of my depth here... is Python
compiled specially for cygwin, or is it the standard Windows Python
that is involved?

If the latter, which I now doubt for some reason, then yes, os.kill()
can kill things spawn with spawnl/v/p/whatever provided that you use
the fake os.kill that I provided before, because os.kill doesn't
normally exist on Windows.

-Peter

 

[Dennis Lee Bieber]

The process it spawns doesn't appear on the ps, and no data gets put
in the database or written to stdout. When it tries to kill the
process it's spawned, I get an error message: "kill 2348: Operation not
permitted", which is different from the message I get if I just kill a
process that doesn't exist, so something is happening, but it isn't
what I want.

p = os.spawnl(os.P_NOWAIT, "/usr/bin/python", "python", "hobo.py",
'/dev/ttyS0', 5)

Pardon, I've not checked the details of os.spawnl() (or others)
but does it translate numeric arguments (the 5) to a format usable for
argv (if C) command line?

Maybe the spawned process is dying on its own before you can
kill it because it wants a quoted '5'?

--

 

[Laura Conrad]

Dennis> p = os.spawnl(os.P_NOWAIT, "/usr/bin/python", "python", "hobo.py",
Dennis> '/dev/ttyS0', 5)

Dennis> Pardon, I've not checked the details of os.spawnl()
Dennis> (or others) but does it translate numeric arguments (the
Dennis> 5) to a format usable for argv (if C) command line?

Dennis> Maybe the spawned process is dying on its own before you can
Dennis> kill it because it wants a quoted '5'?

That was it; thanks.

 

[Stefan Eischet]

Stefan> I sometimes use os.system with pskill from
Stefan> http://www.sysinternals.com/ntw2k/freeware/pskill.shtml -
Stefan> this should do what you want.

I don't see that it really saves me much over using the cygwin kill
command.

Right. The program I use this in doesn't run on cygwin but on "normal"
win32, so I have no kill command there.

Another poster mentioned the possible difference between handles and
pids, which I didn't notice in my case. I only feed the number returned
from the spawn call into pskill, which just does the right thing.

Stefan

// (e-mail address removed) //

 

[Laura Conrad]

Further adventures in infanticide. I've been spawning and killing
programs all day, in the course of testing and fixing other aspects of
the program.

All of a sudden, although I haven't changed the spawn line at all,
only things farther along in the program, I get:

C:\cygwin\bin\python2.3.exe (5684): *** unable to remap C:\cygwin\bin\cygcrypto-0.9.7.dll to same address as parent(0x6B0000) != 0x6C0000
4 [main] python 5468 sync_with_child: child 5684(0x710) died before initialization with status code 0x1
681 [main] python 5468 sync_with_child: *** child state child loading dlls
Traceback (most recent call last):
File "testspawn.py", line 8, in ?
p = os.spawnl(os.P_NOWAIT, "/usr/bin/python", "python", 'run_rad7.py', "/dev/ttyS8", "120", "0", "00560")
File "/usr/lib/python2.3/os.py", line 566, in spawnl
return spawnv(mode, file, args)
File "/usr/lib/python2.3/os.py", line 521, in spawnv
return _spawnvef(mode, file, args, None, execv)
File "/usr/lib/python2.3/os.py", line 489, in _spawnvef
pid = fork()
OSError: [Errno 11] Resource temporarily unavailable

This is the same kind of error that caused me to stop using
pexpect.spawn. Does anyone know what's happening? rebooting does not
cause it to go away. The program I attempting to spawn from my python
program runs fine from the command line.

 

[Franz Steinhäusler]

Stefan> Hi Laura,
Stefan> what a terrible subject line! ;-)

I used to think that when I first started using UNIX in the mid 80's.
But I am now a hardened child-killer.

As for the subject line; I thought at first glance, it was spam.

strange kind of humor.

SCNR

 

[Jean Brouwers]

It looks like there is no space left to fork the subprocess and
load/map the libraries the latter needs.

Maybe there too many processes running already, simultaneously?

/Jean Brouwers

 

[Laura Conrad]

Jean> It looks like there is no space left to fork the subprocess and
Jean> load/map the libraries the latter needs.

Jean> Maybe there too many processes running already, simultaneously?

But if that was it, rebooting would have fixed it, wouldn't it?