supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* rpc.nfsd, rpc.mountd
@ 2005-02-19 14:02 H.M. Dijkstra
  2005-05-06 14:43 ` Richard A Downing FBCS CITP
  0 siblings, 1 reply; 4+ messages in thread
From: H.M. Dijkstra @ 2005-02-19 14:02 UTC (permalink / raw)


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.


Regards,

Harmen Dijkstra


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: rpc.nfsd, rpc.mountd
  2005-02-19 14:02 rpc.nfsd, rpc.mountd H.M. Dijkstra
@ 2005-05-06 14:43 ` Richard A Downing FBCS CITP
  2005-05-17 12:25   ` Gerrit Pape
  0 siblings, 1 reply; 4+ messages in thread
From: Richard A Downing FBCS CITP @ 2005-05-06 14:43 UTC (permalink / raw)


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."



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: rpc.nfsd, rpc.mountd
  2005-05-06 14:43 ` Richard A Downing FBCS CITP
@ 2005-05-17 12:25   ` Gerrit Pape
  2005-05-17 12:54     ` TheOldFellow
  0 siblings, 1 reply; 4+ messages in thread
From: Gerrit Pape @ 2005-05-17 12:25 UTC (permalink / raw)


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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: rpc.nfsd, rpc.mountd
  2005-05-17 12:25   ` Gerrit Pape
@ 2005-05-17 12:54     ` TheOldFellow
  0 siblings, 0 replies; 4+ messages in thread
From: TheOldFellow @ 2005-05-17 12:54 UTC (permalink / raw)


Gerrit Pape wrote:
> On Fri, May 06, 2005 at 03:43:26PM +0100, Richard A Downing FBCS CITP wrote:
> 
>>H.M. Dijkstra wrote:

> 
> 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.
> 
Gerrit,
I'd reached the same conclusions. There are my new scripts for LFS-6.

run:
------------------------
#!/bin/bash
exec 2>&1
# Make sure the statd service is running.
# (the statd service should ensure portmap is running first)
svwaitup /var/service/statd
# Get the nfs service parameters from the LFS standard file
# this sets some envars.
source /etc/sysconfig/nfs-server
# Re-export all directories in /etc/exports
/sbin/exportfs -ra > /dev/null
# start some nfsd threads
/sbin/rpc.nfsd -- $PROCESSES
# Start the rpc.mountd daemon
exec /sbin/rpc.mountd --foreground
------------------------

finish:
------------------------
#!/bin/sh
exec 2>&1
# shut down the nfsd threads.
rpc.nfsd -- 0
------------------------

R.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-05-17 12:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-02-19 14:02 rpc.nfsd, rpc.mountd H.M. Dijkstra
2005-05-06 14:43 ` Richard A Downing FBCS CITP
2005-05-17 12:25   ` Gerrit Pape
2005-05-17 12:54     ` TheOldFellow

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).