Why isn't SIGKILL sent to the whole process group?
Boltar
Can someone explain why under linux if I kill a parent process with
say SIGTERM this signal is sent to the whole process group of that
process (ie any child processes its created as long as they haven't
used setpgrp() ) , but if I use SIGKILL this only gets sent to the
specific process. What is the reason for this different behaviour?
B2003
Nate Eldredge
That's not the behavior I see. I wrote the following short program:
#include <stdio.h>
#include <unistd.h>
int main(void) {
printf("I am the parent, PID %d\n", getpid());
sleep(2);
fork();
for (;;) {
printf("I am PID %d and I'm alive!\n", getpid());
sleep(1);
}
return 0;
}
nate@archdiocese:/tmp$ ./foo
I am the parent, PID 11629
I am PID 11630 and I'm alive!
I am PID 11629 and I'm alive!
I am PID 11630 and I'm alive!
I am PID 11629 and I'm alive!
If in another window, I do 'kill -TERM 11629', PID 11630 continues
running. The same behavior if I do 'kill -KILL 11629'. This is the
same on Linux and FreeBSD.
What exactly are you doing to get the behavior you see? Source code
and/or exact commands would be nice.
Martin Vuille
news:86skr8c...@vulcan.lan:
> Boltar <bolta...@yahoo.co.uk> writes:
>
>> Hi
>>
>> Can someone explain why under linux if I kill a parent process
>> with say SIGTERM this signal is sent to the whole process group
>> of that process (ie any child processes its created as long as
>> they haven't used setpgrp() ) , but if I use SIGKILL this only
>> gets sent to the specific process. What is the reason for this
>> different behaviour?
>
> That's not the behavior I see. I wrote the following short
> program:
>
Perhaps the behaviour he is seeing is that SIGHUP is sent
to all members of the foreground process group when the
session leader terminates.
MV
--
I do not want replies; please follow-up to the group.
Boltar
> If in another window, I do 'kill -TERM 11629', PID 11630 continues
> running. The same behavior if I do 'kill -KILL 11629'. This is the
> same on Linux and FreeBSD.
>
> What exactly are you doing to get the behavior you see? Source code
> and/or exact commands would be nice.
I tried my code out on my home system and it doesn't occur here. There
must be something unusual about my system at work. Very odd.
B2003
ppi
Did u try just to strace the parent ?
The only case I did see that was when a process registered a exit
handler with atexit that pretty much did kill( 0, SIGTERM ). The
exit() being called in the signal handler registered by the parent
(for SIGTERM):
void killMyChildren()
{
kill( 0, SIGTERM );
}
int main()
{
atexit( killMyChildren );
...
}
void sigterm_handler( int sig )
{
exit(1);
}
If you strace the parent maybe you will see it explicitely calling
kill( 0, SIGTERM )
I am coming to this conclusion based on the SIGKILL behaviour: SIGKILL
can not be catched, hence no signal handler can run code on its
reception and no cleanup is done - which is what you expect from any
unix system. This is the behavior you observed, I would say I am not
expecting the kernel to play tricks on you ;-)
The system will not send a signal (like SIGTERM) on any process
behalf. Even SIGHUP is sent by the shell, not the system on his own,
so I'll go with a sigterm handler calling exit or kill(0, SIGTERM)
directly (with proper sihgnal blocking after the 1st run of the signal
handler).
Since this is your code, you would know such details so you may be
using a library that plays tricks on you ...
strace it.
cheers,
-- paulo
Boltar
> Did u try just to strace the parent ?
My mistake , for some reason I thought the child died when I did a
"kill -TERM" , but it only occurs if the parent is running in the
foreground and you ^C or ^\ it when the shell obviously sents SIGINT/
QUIT to the process group of the foreground process.
I should drink more coffee before I post :)
> The system will not send a signal (like SIGTERM) on any process
> behalf. Even SIGHUP is sent by the shell, not the system on his own,
Isn't SIGHUP sent by the terminal controller, not the shell?
B2003
ppi
> Isn't SIGHUP sent by the terminal controller, not the shell?
>
> B2003
yep, sorry - it is sent when a psuedo/virtual terminal is closed, an
many times this is a shell that is attached to it. When receiving this
SIGHUP, it sends SIGHUP (and SIGCONT) to the various processes running
in that shell (forwarding it).
I generalize too much :-)
-- paulo