Here's a job control conundrum for you.
Ben Scott
dragonhawk at gmail.com
Wed Apr 11 18:19:20 EDT 2007
On 4/11/07, Steven W. Orr <steveo at syslang.net> wrote:
> => Hmmm, one correction, though: That shows the signal was *sent*. You
> =>need to use "--wait" to have killall wait and tell you if/when the
> =>signal was *received*.
>
> --wait doesn't return if the signal is received. ... --wait will loop around
> looking to see if the process actually disappears.
Oh. Silly me, I figured the "--wait" option invoked wait(2).
Although now that I think about it, it couldn't, could it? wait(2) is
only good for child processes, right? Phooey.
> There's no delay between the send and receive of a signal.
My terminology might be wrong, but I was referring to the fact that
signals are not processed synchronously. For example, if a process is
in the "interruptible sleep" state, it will not receive *any* signals
until the system call it's blocked on returns. Even SIGKILL will be
delayed. Yes?
>> So, what happens if, instead of using the
>> shell's built-in kill, you do:
>>
>> /bin/kill -1 $PID_OF_ALPINE
>
> It's a mystery... ;-)
???
-- Ben
More information about the gnhlug-discuss
mailing list