10

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

red0ct
  • 4,840
  • 3
  • 17
  • 44
Mandar
  • 693
  • 2
  • 9
  • 19
  • 1
    On Unix SE: https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work – Tien Jan 19 '19 at 09:07

3 Answers3

13

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

Mat
  • 202,337
  • 40
  • 393
  • 406
  • Does that mean when an user application makes a system call it blocks all the signals till that system call returns ? – Mandar Dec 22 '11 at 07:17
  • 1
    It is not "blocked", it's in the "uninterruptible sleep (D)" state. see http://stackoverflow.com/questions/767551/how-to-stop-uninterruptible-process-on-linux – J-16 SDiZ Dec 22 '11 at 07:18
  • 2
    @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..) – J-16 SDiZ Dec 22 '11 at 07:20
  • 1
    What you're describing is called "Disk Sleep", indicated by a "D" in the process status. – Tim Post Dec 22 '11 at 14:08
7

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.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
5

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.

magor
  • 670
  • 10
  • 14
  • 2
    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. – Paul Stelian Apr 14 '19 at 06:59