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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:19 EST