Killing the correct process
Blair P. Houghton
bph at buengc.BU.EDU
Fri Feb 16 07:28:09 AEST 1990
In article <1212 at root44.co.uk> gwc at root.co.uk (Geoff Clare) writes:
>In article <5312 at star.cs.vu.nl> maart at cs.vu.nl (Maarten Litmaath) writes:
>>In article <22332 at adm.BRL.MIL> marwood at ncs.dnd.ca (Gordon Marwood)
>>>[wants to timeout ftp.]
>>
>>How about using the following general purpose script? If that's out of the
>>question, the script might still give you a hint how to solve your problem.
>
>[ extremely complicated script deleted ]
>
>There is a much simpler way than Maarten's.
Edited for brevity...
Called with "foo (time in seconds) (command and arguments)"
>#! /bin/sh
>pid=$$
>(
> sleep "$time"
> # use SIGTERM first to allow process to clean up
> kill $pid >/dev/null 2>&1
At this point, and I'll admit it's a rare possibility, but
not an impossibility, especially on multiprocessor machines,
what happens if the $command (see below) has already exited
and some other process (possibly on another processor) has
begun with the same pid? Or won't that happen while this
backgrounded process is tying up the process-group number?
> sleep 2
> # if process hasn't died yet, use SIGKILL
> kill -$SIGKILL $pid >/dev/null 2>&1
>) &
>
>exec "$command"
I'm trying to implement exactly this control structure in C, now,
and one of my least favorite problems is that of getting
the status of a process I may not own without having to do
system("ps -l##### > /tmp/foo"); /* ##### is the pid */
(or fork-and-exec, etc... Actually, the system() call
wouldn't be much of a diseconomy, because it only has to
execute the ps(1) once or twice after what may be several
hours of sleep()'ing.)
I mean, just how the heck does ps(1) do it? Everything I've seen
implies it goes through /dev/mem one byte at a time.
--Blair
"Oh, lovely..."
More information about the Comp.unix.questions
mailing list