Re: to kill a process ?
On 2009-03-05_16:13:21, Aneurin Price wrote:
> On Thu, Mar 5, 2009 at 3:46 PM, Paul E Condon <pecondon@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
pecondon@mesanetworks.net
Reply to: