On 2009-03-05_16:13:21, Aneurin Price wrote: > On Thu, Mar 5, 2009 at 3:46 PM, Paul E Condon <pecon...@mesanetworks.net> > wrote: > > I have a process that I see in ps, but cannot kill. > > This is happening on a host running Lenny in a small LAN. > > > > I run this to get a display of processes: > > gq:/var/lib/mlocate# ps -Af | less > > ?? ?? ?? ?? ?? ?? ?? ?? ?? --------------- > > > > In this list I find this line: > > root ?? ?? ??9398 ?? ?? 1 ??1 04:59 ? ?? ?? ?? ??00:03:11 > > /usr/bin/updatedb.mlocate > > ?? ?? ?? ?? ??PID ?? ??PPID > > > > I issue the following command: > > gq:/db2/chkpnt# kill -9 9398 > > ?? ?? ?? ?? ?? ?? ??-------------- > > > > I re-run ps as above. The process is still there! What can I do, short of > > rebooting? > > > > Take a look at the output of 'ps 9398', and look at the STAT column. > If it's 'D', then Google for uninterruptible sleep. > I'm afraid I don't have anything specific to mlocate to point you to.
It is STAT=='D', which is, some say, waiting for a response from a disk device. It turns out that processes in this status can't be killed and can't even be investigated in /proc since your process for listing stuff in /proc will, itself, be force into STAT=='D' by the act of trying to list the contents of /proc/<num>/. For some reason, (not so) intelligent design perhaps, ps knows it is in status 'D' and will display that fact without itself getting stuck in status 'D'. But it will tell you this fact only if you ask using BSD style options. 'man proc' does not describe any way of seeing the PIDs of processes that have been spawned in the file tree of the spawning process. Is it true that the spawning process does not keep an internal record of the processes that it has spawned? If it did keep such a record, one might be able to implement a signal that tells it to kill one of its child processes. They do die when it dies. How does that happen, if not during the cleanup during the killing of the parent? enough to not try to display status information on these processes, only the fact that they exist, but not the very useful fact that ps knows enough to NOT try to verify the suspected status of the process, because it might be 'D'. But another way of running ps will tell you that it is status 'D', only NOT that its parent process in PID==1. I think I do not want to kill PID==1. I would like to know what disk device updatedb.mlocate was attempting to access when it got stuck. I think that would be very useful debug information, but it's turning out to be very hard to get at. Any ideas? I call this a bug, but a very deep seated bug. I do know that I CAN kill processes in status 'D' by killing the parent. Why is updatedb.mlocate being spawned directly from initd? If there were an intermediate process whose only function was to be killable, then I could clear this condition by killing it. But that's not the way Debian is currently set up. Again, any ideas? Is there a way to instruct a process to hand off 'parentage' of a process to another process? By parentage I mean give up the parent position in relation to another process to a third process that would become an 'adoptive parent'. Lots of questions, please help. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
