Re: NFS daemons in D state for 2 minutes at shutdown

VDA (VDA@port.imtp.ilyichevsk.odessa.ua)
Fri, 21 Sep 2001 15:46:54 +0300


Hello Trond,
Friday, September 21, 2001, 12:25:22 PM, you wrote:
TM> Bullshit. killall5 is definitely *not* a well accepted method for
TM> shutting down applications. Try doing that while your network is
TM> running via a ppp link...

And what is the well accepted method? I'd like to fix my system,
so please somebody enlighten me...

TM> Some programs *have* to be shutdown in a certain order. All RPC
TM> servers fall into that category.

Somehow, I feel I'm beginning to dislike RPC... Until now,
I see only added difficulties with RPC-based services
compared to "ordinary" ones (http etc).

TM>> So, why modified killall5 does the job?
TM> I've no idea how you modified killall5, but if it manages to kill nfsd
TM> before killing the portmapper, then all will work.

I commented out kill(..SIGSTOP..) / kill(..SIGCONT..) in killall5 source.

TM>> Why not make portmapper+NFS daemons killable by TERM, giving
TM>> them the chance to do proper cleanups rather than abrupt KILL?
TM> NFS daemons *do* perform proper cleanups. That's the whole essence of
TM> your problem - they are waiting on the portmapper to acknowledge that
TM> it has unregistered their service. These are *kernel* daemons and so
TM> KILL acts just like any signal as far as they are concerned.

Hmm... NFS daemons wait for portmapper which is gone.
This reminds me of #include order problems in C.

Why nfsd does not die on TERM? It will have a chance of
unregistering (if portmapper does not bail out upon TERM
but waits for all RPC services to unregister first).
Isn't that going to work?

-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua

- 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/