8

If a linux process is waiting for I/O (i.e it is in SLEEP state) and a SIGKILL signal is issued against it, upon termination (STOPPED state) will it pass through RUNNING or READY state?

In other words, for a process to handle a system interrupt such as one generated by SIGKILL is it necessary to pass through RUNNING or READY state ?

Knowing that under normal circumstances a process can handle an interrupt from kernel and knowing that SIGKILL has a quite contradictory purpose of killing an unresponsive signal, I was doubtful about how much control is given to the process being killed, if any at all.

Radu Stoenescu
  • 3,187
  • 9
  • 28
  • 45
  • `SIGKILL` is an unfortunate example as it is a signal which can't be handled by the receiving process. If your question is unrelated to `SIGKILL` and it is a mere example, consider using another signal to express what you mean. – nemo Apr 02 '13 at 15:41

2 Answers2

10

Signal are "handed off" to a process by the kernel, so sending a signal from processA to processB employs the kernel. When SIGKILL is delivered the kernel does not allow any activity by the process (user mode), specifically process rundown: atexit calls, _exit. Nothing. The process is simply destroyed by the system. This involves some activity in kernel mode. Buffered data is lost. SYSV semaphores and other kernel persistent memory objects are left in memory. It can be a real mess.

If something in kernel memory is causing a hang you use the sysrq interface in linux:

http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html

--to perform whatever semblance of an ordered shutdown you can get.

This is why using SIGKILL is an absolute last resort, because you cannot know what you are breaking. And it will not fix all hangs.

What exactly are you working on?

jim mcnamara
  • 16,005
  • 2
  • 34
  • 51
  • I don't think the OP's question was specific to `SIGKILL`. I understand it rather as "does a process need to be active to handle a signal". – nemo Apr 02 '13 at 15:39
  • A process has to have cpu context to receive signals. SIGKILL is slightly different. Processes have two components - kernel -- sometimes called P0, user land code, call it P1. P0 and P1 are simply returned to paged pool non-paged pool and to system memory when SIGKILL is picked up by the kernel. Some things like semaphores stay in kernel memory. So in this sense P1 never does become active. You definitely could argue that some P0 activity is in process context, but your user mode code cannot do anything about it. – jim mcnamara Apr 02 '13 at 16:13
  • Yes, I know that and your post already says that `SIGKILL` can't be handled. But I don't think that the OP is asking for `SIGKILL` but all signals in general. So, your first sentence of your comment is the answer to the OP's question IMO. – nemo Apr 02 '13 at 16:20
  • A kernel-only process ( a zombie for example) cannot receive a signal, because it does not poll for them. So there is nothing to SIGKILL, anyway. Maybe this is the source of confusion. The kernel "part" does stuff, the user land part does not do "stuff" – jim mcnamara Apr 02 '13 at 16:21
  • @nemo - The answer to that is the process has to be able to poll for signals, which means it has to have process context. It has to be able to access the cpu. True for all signals. – jim mcnamara Apr 02 '13 at 16:23
2

In addition to jim mcnamara's answer:

SIGKILL (kill -9) cannot be handled.

See the answer at https://stackoverflow.com/a/2541618/1456519 for more.

Community
  • 1
  • 1
Victor Burenkov
  • 187
  • 7