Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am seeing processes on my SGI Altix 450 running SLES 10.1 seemingly stop running (i.e. not provide further output in their logs for hours). At this point I want to kill the offending process so I can restart it. Top shows that the process is in the (R) state. Although when I attempt to kill it nothing happens. Even when I use kill -9 it still lingers. In this case what can I do other than restart the machine?

share|improve this question
Are they definitely the same process id? It's not that you're killing the process and some daemon is relaunching a process with the same name? – CK. Jul 21 '09 at 14:03

It is possible that process is killed but waiting for parent to collect its return value. In that case after it is killed it would be in state 'Z' and not 'R'. In that case you should find ppid of process using ps command and kill the parent process too(If you are really sure it wont cause any problems).

The other case could be that for some reason process is restarting after being killed like tty. In that case the process id should change every time you do kill -9. See if process ID is changing every time you are try to kill it.

share|improve this answer
I believe I am trying to kill the parent process. It's the parent process that is in the (R) state. pstree confirms this. The child processes are all in (Z) zombie states. The ppid stays static, thus I don't believe it is simply restarting. – Jared Brown Jul 21 '09 at 14:16
If you kill the parent process (and its parents process and so on) then init will become parent of the child processes which are in 'Z' state and collect their return value. So the best way to remove 'Z' childs whose parent is not taking their return value, is to kill parent as well so that init becomes parent of dead child processes. – Saurabh Barjatiya Jul 21 '09 at 16:37
This is the issue that I am having. Sending a -9 signal via kill to the parent process is not terminating it. – Jared Brown Jul 21 '09 at 19:01
Sending SIGHUP to parent is sometimes enough. You don't always have to kill the parent. – Thomas Jul 22 '09 at 6:17
I'm sorry, SIGCHLD. (too early in the morning) – Thomas Jul 22 '09 at 6:18

The process is waiting on some system resource, perhaps NFS? that is not allowing it to 'let go'. Would love to hear some solutions to this beyond mine...

reboot the box, or let the process sit around.

I wonder if you might be able to 'STOP' the process via kill -STOP {PID} to prevent it from consuming more cpu.

Restarting it should be possible even with another stopped process sitting around, but it may require a list port or shared memory segment that is still in use by the other process.

share|improve this answer
Wouldn't a process that was waiting on NFS or a some I/O function to complete be in a (D) state? These processes are in an (R) state. – Jared Brown Jul 21 '09 at 14:31
This is exactly what is happening to me sometimes when I do the ls command on a s3fs mount. The ls process won't kill even with kill -9 until I force the unmount with umount -l – bleemboy Oct 2 '15 at 15:09

Have you checked dmesg yet? I've seen this after a kernel panic; the only way to recover is to reboot (preferably soon) — and then get a patched kernel.

Normal unkillable processes will be in the D state, not R.

share|improve this answer
Can anything be done about D state die hard processes other than reboot? ppid = 1 – Prof. Moriarty Apr 18 '10 at 20:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.