9

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?

1
  • 2
    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, 2009 at 14:03

3 Answers 3

9

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.

6
  • 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. Jul 21, 2009 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. Jul 21, 2009 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. Jul 21, 2009 at 19:01
  • 1
    Sending SIGHUP to parent is sometimes enough. You don't always have to kill the parent.
    – Thomas
    Jul 22, 2009 at 6:17
  • 2
    I'm sorry, SIGCHLD. (too early in the morning)
    – Thomas
    Jul 22, 2009 at 6:18
2

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.

2
  • 1
    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. Jul 21, 2009 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 Oct 2, 2015 at 15:09
0

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.

1
  • Can anything be done about D state die hard processes other than reboot? ppid = 1 Apr 18, 2010 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .