Re: [bug report] NFS and uninterruptable wait states

[Phillip Susi <psusi@cfl.rr.com>]

That's all well and good that the process won't get an error back, but imho, 
a process should *NEVER* be beyond the reach of a SIGKILL.  I mean, an 
unkillable process prevents a clean shutdown, doesn't it?  ( can't kill the 
process, can't unmount the filesystem ).  

On Monday 03 September 2001 03:50 pm, Doug McNaught wrote:
> Phillip Susi <psusi@cfl.rr.com> writes:
> > The other day I was trying to set up an NFS mount to my room mate's
> > system, and ran into what I at least, call a bug.  When I tried to mount
> > his NFS export, the mount command locked up, and would not die.  Not even
> > a SIGKILL would do any good.  According to ps, the mount process was in
> > the 'D' - uninterruptable wait state.  It also looked like the WCHAN was
> > rpc_ something.  I think it was waiting for an rpc call to return in the
> > D state, and it never did return.  The bug here is that it should NOT be
> > waiting in the D state for something that could never happen.  For that
> > matter, why should anything ever need to wait in an uninterruptable
> > state?  Whenever you wait, you should expect the possibility of being
> > interrupted, check for that when you wake up, and if you were, clean up
> > and return so the signal can be processed.
>
> NFS does this (wait in D state) by default in order to prevent naive
> applications from getting timeout errors that they're not equipped to
> handle--the idea being that, if an NFS server goes down, programs
> using it will simply freeze and recover once it returns, rather than
> getting a timeout error and possibly becoming confused.
>
> If you don't like this behavior, mount with 'soft' and/or 'intr'
> options--see the manpage.
>
> -Doug