Messages in this thread |  | | Date | Fri, 21 Sep 2001 15:46:54 +0300 | From | VDA <> | Subject | Re: NFS daemons in D state for 2 minutes at shutdown |
| |
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/
|  |