[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kill does not stop process



On Tue, Sep 07, 2004 at 02:07:04PM -0700, briand@aracnet.com wrote:
> >>>>> "Justin" == Justin Guerin <jguerin@cso.atmel.com> writes:
> 
>   Justin> uninterruptable sleep.  If it is, there's nothing you can do
>   Justin> about it, except reboot.  Also note, that each process in
>   Justin> uninterruptable sleep will count as 1 in your load average,
>   Justin> even if it's not taking any cpu / network / disk resources.
> 
>   Justin> I haven't done this myself, but you might check out the
>   Justin> other threads about CD writing in 2.6.8 to get some pointers
>   Justin> about how to get cdrecord to complete successfully.  I
>   Justin> believe you may need to specify the device.  Of course, this
>   Justin> assumes you're using a 2.6.x kernel.  If you're not, I'm not
>   Justin> really sure why cdrecord would hang.
> 
> Which brings up a more interesting question : why isn't just aout
> every process killable ?
> 
> After all if I tell the kernel to kill process x, why can't the
> scheduler at the next opportunity just clobber the process, take away
> it's interrupts (by masking or overwriting the interrupt vector or
> whatever) , etc...
> 
> Is it because hardware oriented tasks run at the same level as the
> scheduler, and so it is unable to ?
> 
> It seems very odd that a process should ever become "unkillable".
> There must be a very fundamental limitation in the way the kernel
> works to cause such a problem.

It would be trivial to patch the kernel to be able to kill
TASK_UNINTERRUPTABLES.  (For 2.2.20, editing line 731 of kernel/sched.c
should enable it).  Uninterruptable Sleep exists for a reason.  Suppose a
process is doing some fairly major disk operation. (ReiserFS tree grow?)
You decide it is taking a long, so you -9 it.  Since the process is in
uninterruptable sleep, the kill will not happen until the filesystem is
in a sane state.  If we didn't have D, not only would it be possible to
kill processes in critical regions, but suppose a process on an SMP box
died while holding the global kernel lock? Instant, total, lockup.

-- 
The world's most effective spam filter:
        ln -sf /dev/full /var/mail/$USER



Reply to: