On 10/1/13 7:04 AM, Job Noorman wrote:
> Hi all,
>
> I just noticed some strange behavior with the kill builtin and was wondering
> whether
> this is a bug or not. The following applies to using kill on stopped
> processes (I didn't
> test it on running processes).
>
> When using 'kill jobspec', the SIGTERM signal is sent to the process followed
> by a
> SIGCONT. The net result is the process immediately receiving SIGTERM and,
> normally,
> being terminated.
>
> When using 'kill pid', however, only SIGTERM is sent. This means the process
> won't
> receive the signal before being (manually) resumed.
When you use job control notation, it's clear that you're signaling a
process group. Bash knows this and, since the process group is the
unit of job control, assumes that you want to send the same signal to
each process in the process group. To make sure that all processes get
termination signals and handle them in a timely fashion, bash sends
SIGCONT to stopped jobs to which you send SIGTERM or SIGHUP. This is a
user convenience feature.
When you use a numeric pid argument, Bash makes no assumptions about
whether or not you mean a process group and simply sends the requested
signal. If the pid is < -1, bash sends the requested signal to the
process group named by -pid. This is how kill(2) works.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
