supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Gerrit Pape <pape@smarden.org>
Subject: Re: rpc.nfsd, rpc.mountd
Date: Tue, 17 May 2005 12:25:28 +0000	[thread overview]
Message-ID: <20050517122528.16814.qmail@93361de9ea22df.315fe32.mid.smarden.org> (raw)
In-Reply-To: <427B828E.8080501@109bean.org.uk>

On Fri, May 06, 2005 at 03:43:26PM +0100, Richard A Downing FBCS CITP wrote:
> H.M. Dijkstra wrote:
> > I'm an enthuisast runit user, all services I had planned to run under runit 
> > are running well. However I'm in need for some clarification on the behaviour 
> > of rpc.nfsd and all the other rpc.* which are part of the nfs-utils package. 
> > I observe the following: 
> > 
> > First I link in rpc.statd, which runs fine and stays 'parked' under runsv. 
> > Then
> > I start rpc.mountd, a run script similar to yours on your site, section
> > runscripts. Being completely hooked on the idea of having *all* processes
> > started by runit monitored by runit I see rpc.mountd remaining 'parked' under
> > runit, but the 8 threads of nfsd and 1 thread of lockd jumped ship and are 'on
> > their own' sitting in the root process tree. Ok, I might sound a nit esoteric 
> > so
> > I'll provide an example here:
> > 
> > --------example----------
> > 1738 ?        S      0:00  \_ runsv nfs.mountd
> > 2656 ?        S      0:00  |   \_ /command/svlogd -tt
> > /var/log/supervise/nfs.mountd
> > 2671 ?        S      0:00  |   \_ /usr/sbin/rpc.mountd -F --no-nfs-version 2
> > --nfs-version 3
> > 1739 ?        S      0:00  \_ runsv nfs.statd
> > 2607 ?        S      0:00  |   \_ /command/svlogd -tt
> > /var/log/supervise/nfs.statd
> > 2622 ?        S      0:00  |   \_ /sbin/rpc.statd -F
> > 1740 ?        S      0:00  \_ runsv portmap
> > 1744 ?        S      0:00  |   \_ /command/svlogd 
> > -tt /var/log/supervise/portmap
> > 1826 ?        S      0:00  |   \_ /sbin/portmap -d
> > 1742 ?        S      0:00  \_ runsv crond
> > 1753 ?        S      0:00      \_ /command/svlogd -tt /var/log/supervise/crond
> > 2578 ?        S      0:00      \_ crond -d1 -l10
> > 2683 ?        S      0:00 [nfsd]
> > 2684 ?        S      0:00 [nfsd]
> > 2685 ?        S      0:00 [nfsd]
> > 2686 ?        S      0:00 [nfsd]
> > 2687 ?        S      0:00 [nfsd]
> > 2688 ?        S      0:00 [nfsd]
> > 2689 ?        S      0:00 [nfsd]
> > 2690 ?        S      0:00 [nfsd]
> > 2691 ?        S      0:00 [lockd]
> > --------example----------
> > 
> > I don't mind this per se, because I know these nfsd en lockd threads are
> > kernelspace processes and cannot be controlled by your runit for that 
> > particular
> > reason and even if it could I suppose this would mean a too much of burden to
> > control by means of context switching. This however also means the threads
> > cannot be killed using runit. If I want to do that I have to resort to manual
> > hard killing (-1, -9)
> > 
> > And now the questions:
> > 
> > 1) Am I right in stating that this is the normal behaviour or is there 
> > something
> > wrong with my run script? I suppose not, but it would be very nice to have 
> > this
> > confirmed by you. Server is now production ready as far as I am concerned but
> > I'm not 100% sure about this yet, regarding nfs. 
> > 
> > 2) Is it advisable to have a 'kill all nfsd/lockd threads by pid` in the 
> > finish
> > script yes?
> > 
> > I would be very thankful if anybody could enlighten me with these last bits 
> > for my perfect server.
> 
> No one ever answered this old question.  Now I'm at that point too, and
> have the very same set of questions.
> 
> Does anyone know how to use runit to control a standard Linux NFS server
> set up?  The mountd script on Gerrit's website don't work for me as the
> rpc.mountd process and the nfsd processes remain after the run script
> terminates.  Adding, say, kill -HUP `pidof nfsd` to a finish script
> removes the nfsd threads together with the lockd thread, but the
> rpc.mountd process doesn't terminate without an explicit kill too.

Hi, looks like the mountd run script on the web page isn't accurate, it
should 'exec' into rpc.mountd, e.g.:

 #!/bin/sh
 exec 2>&1
 RPCNFSDCOUNT=8  # Number of servers to be started up by default
 RPCMOUNTDOPTS=-F
 exportfs -r
 rpc.nfsd -- $RPCNFSDCOUNT
 rpcinfo -u localhost nfs 3 >/dev/null 2>&1 || \
   RPCMOUNTDOPTS="$RPCMOUNTDOPTS --no-nfs-version 3"
 exec rpc.mountd $RPCMOUNTDOPTS

Stopping the service will still leave the nfsd (and lockd) threads
running though.  I don't like the pid-guessing applications like pidof
or start-stop-daemon, a `rpc.nfsd -- 0` in ./finish maybe can help here.

HTH, Gerrit.


  reply	other threads:[~2005-05-17 12:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-19 14:02 H.M. Dijkstra
2005-05-06 14:43 ` Richard A Downing FBCS CITP
2005-05-17 12:25   ` Gerrit Pape [this message]
2005-05-17 12:54     ` TheOldFellow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050517122528.16814.qmail@93361de9ea22df.315fe32.mid.smarden.org \
    --to=pape@smarden.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).