Is there some cases in which SIGKILL will not work?

Question

Are there any cases where an application running on Linux, which has not blocked signal SIGKILL, will not get killed on firing SIGKILL signal?

Accrete

On Unix SE: unix.stackexchange.com/questions/5642/… – Hinny

Answer 1

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.)

Bates

Does that mean when an user application makes a system call it blocks all the signals till that system call returns ? – Accrete

It is not "blocked", it's in the "uninterruptible sleep (D)" state. see #768051 – Lifton

@Mandar, no. you can't "block all the signal". The D state is something internal to kernel (e.g. Reading from CD-ROM, syncing to disk etc..) – Lifton

What you're describing is called "Disk Sleep", indicated by a "D" in the process status. – Ibo

Answer 2

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.

Riggle

Answer 3

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.

Unanimous

The SIGKILL signal will still be pending and if somehow the system gets unstuck on that process it will automatically handle it (exiting the process) upon return to userspace. – Roseleeroselia