[lkml]   [2001]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [bug report] NFS and uninterruptable wait states
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 <> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.127 / U:1.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site