From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/806 Path: news.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: rpc.nfsd, rpc.mountd Date: Tue, 17 May 2005 12:25:28 +0000 Message-ID: <20050517122528.16814.qmail@93361de9ea22df.315fe32.mid.smarden.org> References: <200502191502.39778.harmend@planet.nl> <427B828E.8080501@109bean.org.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1116332905 17581 80.91.229.2 (17 May 2005 12:28:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 17 May 2005 12:28:25 +0000 (UTC) Original-X-From: supervision-return-1042-gcsg-supervision=m.gmane.org@list.skarnet.org Tue May 17 14:28:22 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by ciao.gmane.org with smtp (Exim 4.43) id 1DY17l-0000Je-PK for gcsg-supervision@gmane.org; Tue, 17 May 2005 14:24:38 +0200 Original-Received: (qmail 454 invoked by uid 76); 17 May 2005 12:25:33 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 449 invoked from network); 17 May 2005 12:25:33 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <427B828E.8080501@109bean.org.uk> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:806 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:806 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.