> 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
-- Free Dmitry Sklyarov! http://www.freesklyarov.org/We will return to our regularly scheduled signature shortly. - 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/