NFS daemons in D state for 2 minutes at shutdown

NFS daemons in D state for 2 minutes at shutdown

[VDA]

Hi NFS folks,

I am still fighting witn nfsd/lockd not dying upon killall5.
(they are stuck in D state for 2 mins and then die with
"rpciod: active tasks at shutdown?!" at console)

I found out that nfsd and lockd die as expected when I use
modified killall5 which do not SIGSTOP all tasks before
killing them.

Any idea why this makes such difference? Is this a bug in
nfsd/lockd or in killall5?
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua

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

[Trond Myklebust]

>>>>> " " == VDA  <VDA@port.imtp.ilyichevsk.odessa.ua> writes:

     > Hi NFS folks, I am still fighting witn nfsd/lockd not dying
     > upon killall5.  (they are stuck in D state for 2 mins and then
     > die with "rpciod: active tasks at shutdown?!" at console)

     > I found out that nfsd and lockd die as expected when I use
     > modified killall5 which do not SIGSTOP all tasks before killing
     > them.

     > Any idea why this makes such difference? Is this a bug in
     > nfsd/lockd or in killall5?

killall5 is a bad idea as a method for killing nfsd/lockd. You are
better off using something more targeted so you can ensure the correct
ordering.
If you kill the portmapper before the nfs/lockd daemons have finished
unregistering their services then the above behaviour is completely
normal.

Cheers,
  Trond

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

[Trond Myklebust]

>>>>> " " == VDA  <VDA@port.imtp.ilyichevsk.odessa.ua> writes:

     > Well, do you mean I must update my shutdown script whenever I
     > install something new just because this "something new" does
     > not like standard, well accepted method of signalling apps to
     > exit?  Come on, this sounds like The Wrong Way.

Bullshit. killall5 is definitely *not* a well accepted method for
shutting down applications. Try doing that while your network is
running via a ppp link...

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

     > So, why modified killall5 does the job?

I've no idea how you modified killall5, but if it manages to kill nfsd
before killing the portmapper, then all will work.

     > Why not make portmapper+NFS daemons killable by TERM, giving
     > them the chance to do proper cleanups rather than abrupt KILL?

NFS daemons *do* perform proper cleanups. That's the whole essence of
your problem - they are waiting on the portmapper to acknowledge that
it has unregistered their service. These are *kernel* daemons and so
KILL acts just like any signal as far as they are concerned.

Cheers,
   Trond

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

[Trond Myklebust]

>>>>> " " == VDA  <VDA@port.imtp.ilyichevsk.odessa.ua> writes:

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

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

Use a combination of 'ps' and 'kill -9' or even 'killall'. Anything
that actually selects the nfsd daemons and *NOT* the portmapper.
Grab a copy of nfs-utils and look at the init script included
there if you still don't understand...

Cheers,
  Trond

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

[Mike Castle]

On Sat, Sep 22, 2001 at 01:06:28AM +0200, Trond Myklebust wrote:
> Use a combination of 'ps' and 'kill -9' or even 'killall'. Anything
> that actually selects the nfsd daemons and *NOT* the portmapper.


Personally I'd suggest NOT getting into the habit of using killall.  It
performs like killall5 does on SysV machines.  So if you forget which
machine you're on....

My personal favorite for years was /bin/kill <process name>.  However, it
depends on which package your system actually uses for /bin/kill (the kill
from util-linux can kill by name, the procps one can not).

Lately I've been trying to train myself into using skill (from procps).

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

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

[VDA]

Hello Trond,

Thursday, September 20, 2001, 8:15:21 PM, you wrote:
TM>      > Hi NFS folks, I am still fighting witn nfsd/lockd not dying
TM>      > upon killall5.  (they are stuck in D state for 2 mins and then
TM>      > die with "rpciod: active tasks at shutdown?!" at console)

TM>      > I found out that nfsd and lockd die as expected when I use
TM>      > modified killall5 which do not SIGSTOP all tasks before killing
TM>      > them.

TM> killall5 is a bad idea as a method for killing nfsd/lockd. You are
TM> better off using something more targeted so you can ensure the correct
TM> ordering.

Well, do you mean I must update my shutdown script whenever I install
something new just because this "something new" does not like
standard, well accepted method of signalling apps to exit?
Come on, this sounds like The Wrong Way.

TM> If you kill the portmapper before the nfs/lockd daemons have finished
TM> unregistering their services then the above behaviour is completely
TM> normal.

So, why modified killall5 does the job?

Why not make portmapper+NFS daemons killable by TERM, giving them
the chance to do proper cleanups rather than abrupt KILL?
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua

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

[VDA]

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