supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Richard A Downing FBCS CITP <richard@109bean.org.uk>
Subject: Re: rpc.nfsd, rpc.mountd
Date: Fri, 06 May 2005 15:43:26 +0100	[thread overview]
Message-ID: <427B828E.8080501@109bean.org.uk> (raw)
In-Reply-To: <200502191502.39778.harmend@planet.nl>

H.M. Dijkstra wrote:
> Hello everybody,
> 
> 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.

Regards,

-- 
Richard A Downing FBCS CITP http://www.109bean.org.uk/
"The sole purpose of stupid people is to teach clever people what not to
do."



  reply	other threads:[~2005-05-06 14:43 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 [this message]
2005-05-17 12:25   ` Gerrit Pape
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=427B828E.8080501@109bean.org.uk \
    --to=richard@109bean.org.uk \
    /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).