RE: [TCLUG:7184] Process killing

[Unni Nambiar <unambiar@Legato.COM>]

> -----Original Message-----
> From: JellyD [mailto:jellyd@jellyd.org]
> Sent: Sunday, July 25, 1999 8:44 PM
> To: tclug-list@mn-linux.org
> Subject: Re: [TCLUG:7184] Process killing
> 
> 
> On Sun, 25 Jul 1999 schewe@tcfreenet.org wrote:
> 
> > > How do I kill a process that's in an IO wait state ?
> > 
> > reboot.
> 
> That's not the answer I was looking for, of course :P
> 
> There's got to be _SOME_ way. I don't want to stoop to the
> Microsoft fix.
> 
> In the off chance that a 'killall -HUP crond' was somehow
> magically killing it and respawning it with the same set of
> PIDs, I moved the crond executable to a new inode and renamed
> it before doing so. No dice.
> 
> I can't seem to signal them anything. I can, however, renice
> them to -19 .. which, given that they're all just sitting in a
> wait state, doesn't do a damn thing.
> 
> I tried every signal from 'kill -l' to no avail. I think
> I'm going to hafta add support for this to my kernel; it's kind
> of obnoxious. 
> 

Probably a stupid question.  But did you try kill -9.

The -9 signal cannot be trapped by an application and is therefore almost
guaranteed to terminate any hanging process.  I say almost because, in
certain cases when the application switches from the user code to the kernel
code, even -9 does not work.  In this case you have no choice but to either
wait for the problem to correct itself (internal timeout if any eg. wait
states in socket operations) or ... reboot (*shudder*).

Since you say there are a ton of such processes, first thing you want to do
is remove the offending process from the cron tab.

I don't know what you meant by adding support for this to the kernel, but
usually the application is the one at fault by not protecting itself against
this possibility.  Of course, i suppose a kernel can be designed to
guarantee no hangs in kernel code.  Idle question.  Does anyone know if this
is a feature of the linux kernel.

Good Luck.

-Unni