Reputation: 8087
The old way "signal" and new way "sigaction": can SIG_KILL be handled safely by our program? Is there a difference between different linux kernel version on this? I was trying to upgrade from 2.6.30 to a higher version and with to know from development perspective, can this SIG_KILL be handled safely?
Upvotes: 2
Views: 513
Reputation: 3123
No. As Matteo Piano pointed out, we're not supposed to be able handle SIGKILL using a signal handler. There shouldn't be a difference in this regard between different kernel versions unless we're talking about a buggy version or an otherwise non-standard version.
From the "Standard signals" section of man 7 signal:
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
If one were determined enough though, one could download the Linux kernel sources and change it to do whatever they'd like. But I wouldn't suggest allowing SIGKILL to be caught and I wouldn't call it "safe" if one did. You could wind up having to do hardware resets to get processes to stop.
As you don't specify in your question why you'd want to catch SIGKILL,
you may want to consider using another signal like SIGHUP
, SIGINT
or SIGQUIT
instead. These other signals are meant for possibly being handled and some Unix/Linux programs do just that.
Alternatively (to catching SIGKILL), you may also want to consider having a process sit around to detect whether the target process exits. A parent process for instance could look for a SIGCHLD
signal from the child exiting and then effectively cause the same events to occur that you had hoped to do in your signal handler.
Upvotes: 1