On Tue, Sep 07, 2004 at 02:07:04PM -0700, [EMAIL PROTECTED] wrote:
> >>>>> "Justin" == Justin Guerin <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
