Mailinglist Archive: opensuse (6210 mails)

[Randall R Schulz <rschulz@xxxxxxxxx>]

Sid,

On Tuesday 18 October 2005 13:07, Sid Boyce wrote:
> Randall R Schulz wrote:
> > ...
> >>
> >> # cat /proc/proc_number/Status | grep -v State
> >>
> >>           State:  D (disk sleep)
> >>
> >> What's it?
> >
> > It's what the parenthetical says: A process sleeps in a D state
> > when it's waiting for disk I/O. In practice, it is not necessarily
> > a disk per se that's being waited for, but what all use of D sleeps
> > have in common is that the event that ends the sleep will come very
> > quickly (well under one second). When this doesn't happen and a
> > process is seen to persist in a D sleep, it's a de facto sign of a
> > problem. D sleeps and all sleeps at internal priority less than 0
> > cannot be interrupted by signals.
> >
> >> ...
> >
> > Randall Schulz
>
> What I've wondered about for a long time is why a method to nuke such
> tasks can't be found. There must be a reason or it would have been
> done a long time ago.

Of course a method could be found. It simply must not be allowed.

If you allow signals to interrupt negative-priority sleeps, the 
integrity of the internal data structures they protect cannot be 
guaranteed. In practice what you'd likely see if you did it is 
spreading rot in the kernel data structures.

The only solution is to correct the software errors that are positively 
indicated by a persistent D sleep.


> ...
>
> Sid.


Randall Schulz