not all signals are equal!

[Daneel Yaitskov]

Hi All,

I have written small daemon by bash. I thought before
this program that all signals, excepting SIGKILL, SIGSEG and STOP,
equal. I have found following difference of SIGTERM from other for
root's process in new session. Namely, if this process wait his child:

setsid bash -c "while : ; do echo \$$ ; sleep 1000 ; done"

then it ignores usual signals such as SIGQUIT and SIGINT except SIGTERM.
I send signals to this process as root. These signals are ignored at
all. I tested it hanging handler, printing messages, on SIGQUIT and SIGINT.

I have Ubunut 8.10.

Is this a kernel's bug?

Daneel Yaitskov.

[WANG Cong]

Nope.

Both SIGQUIT and SIGINT can be generated from keyboard, the new
session will not be sent to these tty signal as long as it
doesn't control the terminal. In this case, the session who controls
the terminal is still the old one, not the new one your created by
bash, thus these 2 signals will not be sent, SIGTERM will do, since
it is not from terminal.

[Arcege]

The setsid does not tell the process to ignore any signals. It tells
the process change the session id. As Wang Cong pointed out, this
will cause the keyboard control to change. But the process itself is
still responding to all signals in the same way as before. Try
sending different signals using kill to the sleep process and to the
bash process.

If you want your program to stop responding to signals, then you will
need to set up handlers for them, using "trap". For example, "trap ''
HUP INT QUIT TERM" will tell the program to ignore all these signals.
And the only ones that cannot be ignored are as you mentioned: SIGKILL
and SIGSTOP. I believe that it may be system dependent as to whether
SIGSEGV is ignorable or not.

-Arcege