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