Menu
Are there any cases where an application running on Linux, which has not blocked signal SIGKILL, will not get killed on firing SIGKILL signal?
656
When a process receives SIGKILL it is terminated. This is a special signal as it can't be ignored and we can't change its behavior. We use this signal to forcefully terminate the process.
Signals that cannot be ignored (SIGKILL and SIGSTOP) cannot be blocked. Signals can cause the interruption of a system call in progress, leaving it to the application to manage a non-transparent restart.
The trap in the example above executes the cleanup function when it detects one of the four signals: SIGHUP , SIGINT , SIGQUIT , or SIGABRT . The signals are referred to by their number. Note: The SIGKILL signal cannot be trapped. It always immediately interrupts the script.
The signals SIGKILL or SIGStop cannot be blocked. Any attempt to use sigprocmask() to block these signals is simply ignored, and no error is returned.
SIGKILL cannot be blocked or ignored (SIGSTOP can't either).
A process can become unresponsive to the signal if it is blocked "inside" a system call (waiting on I/O is one example - waiting on I/O on a failed NFS filesystem that is hard-mounted without the intr option for example).
(Another side case is zombie processes, but they're not really processes at that point.)
153
Yes, when the process is blocked in kernel space, e.g. reading on a blocked NFS file system, or on a device which does not respond.
38
Check with ps a (or you can use other flags as well) the process state.
If a process state is
D : uninterruptible sleep (usually IO)
then you cannot kill that process.
As others mentioned, and as it is defined, this is usually caused by a stuck I/O, for example process waiting to do I/O to a disconnected NFS file system.
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
