S6 init system with s6-66 service manager in Antix-init-diversity spin

[nevj (Neville Jackson)]

I looked at that. It is set?
I am in the virt-manager display, in an X terminal in Antix, and the DISPLAY is :0.0…
I get that Gtk message if I try to start spice-vdagent in S6-66
I do not get the message if I start spice-vdagent by hand

Dont panic. This is a minor issue.
I think 66 is having trouble with a daemon that needs to talk to X11. spice-vdagent has to track the mouse and deal with the clipboard. That is complicated and involves X.

I am going to look at another distro where spice-vdagent works
automatically… probably Devuan.

I tried with xeyes instead of spice-vdagent… move to something simpler
This was done as root
Same result
66 start xeyes
starts xeyes, then it stops , without bringing up anything on the screen.
similar message

Log destination       : /var/log/66/xeyes
Log file              : 
Error: Can't open display: 
Error: Can't open display: 
Error: Can't open display: 

There is something about processes that interact with X that does not work
under s6-66.
Am I doing something foolish? xeyes is not a daemon. Can I not use a normal
app as daemon? Is that the problem?

I found this

daemonize(1): run program as Unix daemon - Linux man page

maybe that answers the question.
Most programs intended to be daemons look after a few details, but if you have a program that does not, you need to use
the daemonize command.

[obarun]

@nevj

There is something about processes that interact with X that does not work
under s6-66.

Nope, 66 is not the trouble but how you declare your user service.
Append this at the end of your frontend file

[environment]
DISPLAY=:0.0

and reconfigure your service.
Now the DISPLAY variable will be set as environment variable of your service.

[nevj (Neville Jackson)]

@obarun

[environment]
DISPLAY=:0.0

and reconfigure your service.

Yes that works, thank you

It also required xhost + in the controlling terminal.
So S6 needs to be told about DISPLAY, independently of it being set in the terminal.

Now, back to spice-vdagent as root
add the following to the frontend

[environment]
DISPLAY=:0.0

reconfigure
and , yes it works…

root@antix-init-diversity:/home/nevj# ps ax | grep spice
 5526 ?        S      0:00 s6-supervise spice-vdagentd-log
 5527 ?        S      0:00 s6-supervise spice-vdagentd
 5534 ?        Ss     0:00 /usr/bin/s6-log -d3 n3 s1000000 /var/log/66/spice-vdagentd
 5538 ?        Ssl    0:00 /sbin/spice-vdagentd -x -d
 5634 ?        S      0:00 s6-supervise spice-vdagent-log
 5635 ?        S      0:00 s6-supervise spice-vdagent
 5648 ?        Ss     0:00 /usr/bin/s6-log -d3 n3 s1000000 /var/log/66/spice-vdagent
 5652 ?        Ssl    0:00 /usr/bin/spice-vdagent -x

and copy/paste works.
So, even though spice-vdagent only uses the mouse, it needs DISPLAY defined
in s6.
If I do xhost -
spice-vdagent still runs and works
but if I stop it, it will not start unless I do xhost +
so It only checks authorization when it is started.

Now, back to spice-vdagent as user nevj.
What is supposed to happen is

• spice-vdagentd runs as a longrun daemon
• when a user starts an X session, one copy of spice-vdagent is supposed to
  be started
  so
• I dont want to use 66 start spice-vdagent as nevj
• I dont want to use 66 enable spice-vdagent to start it at boot
• I want spice-vdagent to start wheen an X session is commenced by a user.

Is that possible in s6-66? Or should I be doing that as part of the users X session?
The only distro that does it properly is Debian - so it may require systemd for it to work. There is code in spice-vdagentd that is systemd specific, and it is this part of the code that detects X sessions, and presumably signals the user session to start spice-vdagent.

If this is not a job for s6-66, I think I should abandon spice-vdagent and go on to more interesting aspects of 66.

Thanks for assistance.

Update:
spice-vdagent will now start as user nevj
It needs the same DISPLAY=:0.0 setting in the frontend, and a reconfigure, then

$xhost +
$ (66 scandir start -e /etc/66/environment&)&
[1] 2603
nevj@antix-init-diversity:~
$ scandir: info: create scandir /run/66/scandir/1000 ...

[1]+  Done                    ( 66 scandir start -e /etc/66/environment & )
nevj@antix-init-diversity:~
$ 66 start spice-vdagent
start: info: Initialized successfully: spice-vdagent
start: info: Initialized successfully: spice-vdagent-log
signal: info: Successfully started service: spice-vdagent-log
signal: info: Successfully started service: spice-vdagent
nevj@antix-init-diversity:~
$ ps ax | grep spice
 1469 ?        S      0:00 s6-supervise spice-vdagentd-log
 1470 ?        S      0:00 s6-supervise spice-vdagentd
 1477 ?        Ss     0:00 /usr/bin/s6-log -d3 n3 s1000000 /var/log/66/spice-vdagentd
 1481 ?        Ssl    0:00 /sbin/spice-vdagentd -x -d
 2725 pts/0    S      0:00 s6-supervise spice-vdagent-log
 2726 pts/0    S      0:00 s6-supervise spice-vdagent
 2733 ?        Ss     0:00 /usr/bin/s6-log -d3 n3 s1000000 /home/nevj/.66/log/spice-vdagent
 2739 ?        Ssl    0:00 /usr/bin/spice-vdagent -x

and copy/paste works.

So the only issue with user daemons is having to start the scandir every time
one boots. That means one can not use 66 enable for user daemons.
One would probably not want to enable a user daemon anyway.

[obarun]

@ProwlerGr

Can you update your package to that release. It should fix the module reconfiguration issue.

I see some confusing sentence and association between behavior of daemon and service manager expectations. For instance,

@nevj

So S6 needs to be told about DISPLAY, independently of it being set in the terminal.

or

@nevj

So, even though spice-vdagent only uses the mouse, it needs DISPLAY defined
in s6.

This is not specific to the service manager but specific to the daemon that you want to manage. S6 don’t known anything and have nothing to do with the requirements of environment variable of the daemon. S6, and so 66, give you the tools to be able to pass any environment variables that you want. But, it’s not the role of 66 to decide which one, you need to be specific. 66 works on mechanism not on policies like S6 do. Others service manager may work on policies (deeply). That’s not better or worse, these two ways are just different.

@nevj

Is that possible in s6-66?

yes, in many ways. The shorter and simpler, use the boot-user@ service. It will

• define some well-known environment variables
• configure your ~/.xsession or ~/.xinitrc file execute some important task before launching your desktop.
• start the scandir for the user when in logon with that variables
• start any enabled trees of the user

But you can accomplish the same manually. boot-user@ is not mandatory on 66. No services at all are mandatories on 66 (another difference between others services managers). That also means that you have the complete control of how you configure your services structures and their relative environment variables.

@nevj

If this is not a job for s6-66

Actually, it is.

@nevj

So the only issue with user daemons is having to start the scandir every time
one boots. That means one can not use 66 enable for user daemons.
One would probably not want to enable a user daemon anyway.

Hell no! That’s the contrary, you can start automatically any scandir for any users with any privileges with any environment variables even on different live directory location! But to do that you need to build it. 66 will not do it for you :).

[nevj (Neville Jackson)]

@obarun

. 66 works on mechanism not on policies like S6 do. Others service manager may work on policies (deeply).

I like that.
Policies are something you have when you dont know what to do or how to do it.

Thanks for the responses.
I will try boot@user service.
At moment I have moved on to trees .

[ProwlerGr]

@obarun

Can you update your package to that release . It should fix the module reconfiguration issue.

Nice one Eric, I managed to get the session tree working on antiX, & the user scandir persists.

$ sudo 66 -z tree status -go name,contents
Name        : global
Contents    : \
              ├─dbus-log (pid=1060, state=Enabled, type=classic, tree=global)
              ├─seatd-log (pid=1067, state=Enabled, type=classic, tree=global)
              ├─slimski-log (pid=1066, state=Enabled, type=classic, tree=global)
              ├─connmand-log (pid=1065, state=Enabled, type=classic, tree=global)
              ├─nmbd-log (pid=1056, state=Enabled, type=classic, tree=global)
              ├─smbd-log (pid=1057, state=Enabled, type=classic, tree=global)
              ├─ufw (pid=up, state=Enabled, type=oneshot, tree=global)
              ├─bluetoothd-log (pid=1068, state=Enabled, type=classic, tree=global)
              ├─sshd-log (pid=1063, state=Enabled, type=classic, tree=global)
              ├─scandir@antix:svscan@antix-log (pid=983, state=Enabled, type=classic, tree=global)
              ├─scandir@antix (pid=up, state=Enabled, type=module, tree=global)
              ├─dbus (pid=1081, state=Enabled, type=classic, tree=global)
              ├─seatd (pid=1088, state=Enabled, type=classic, tree=global)
              ├─nmbd (pid=1083, state=Enabled, type=classic, tree=global)
              ├─smbd (pid=1078, state=Enabled, type=classic, tree=global)
              ├─sshd (pid=1087, state=Enabled, type=classic, tree=global)
              ├─scandir@antix:svscan@antix (pid=990, state=Enabled, type=classic, tree=global)
              ├─connmand (pid=1105, state=Enabled, type=classic, tree=global)
              ├─bluetoothd (pid=1106, state=Enabled, type=classic, tree=global)
              └─slimski (pid=1104, state=Enabled, type=classic, tree=global)

Name        : boot
Contents    : \
              ├─elogind-log (pid=0, state=Disabled, type=classic, tree=boot)
              ├─dbus-log (pid=1060, state=Enabled, type=classic, tree=global)
              ├─boot@system:system-hostname (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-run (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-tmp (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:populate-sys (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-pts (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-shm (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:populate-dev (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-cgroups (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-sysctl (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:udevd-log (pid=340, state=Enabled, type=classic, tree=boot)
              ├─boot@system:tty-earlier@tty12 (pid=265, state=Enabled, type=classic, tree=boot)
              ├─boot@system (pid=up, state=Enabled, type=module, tree=boot)
              ├─dbus (pid=1081, state=Enabled, type=classic, tree=global)
              ├─boot@system:populate-run (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:populate-tmp (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─elogind (pid=0, state=Disabled, type=classic, tree=boot)
              ├─boot@system:mount-branch (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-hwclock (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-random (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:udevd (pid=455, state=Enabled, type=classic, tree=boot)
              ├─boot@system:udevadm (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-fontnkey (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-fsck (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-fstab (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-branch (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-rw (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-authfiles (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-swap (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-loop (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-sethostname (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-time (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-dmesg (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-branch (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:runtime-branch (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:canopy (pid=up, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:tty-rc@tty1 (pid=1193, state=Enabled, type=classic, tree=boot)
              └─boot@system:tty-rc@tty2 (pid=1192, state=Enabled, type=classic, tree=boot)

Name        : session
Contents    : \
              ├─boot-user@antix:mount-run@antix (pid=up, state=Enabled, type=oneshot, tree=session)
              ├─boot-user@antix (pid=up, state=Enabled, type=module, tree=session)
              ├─scandir@antix (pid=up, state=Enabled, type=module, tree=global)
              ├─scandir@antix:svscan@antix-log (pid=983, state=Enabled, type=classic, tree=global)
              └─scandir@antix:svscan@antix (pid=990, state=Enabled, type=classic, tree=global)

Now I just need to create good package debs for antiX.

[nevj (Neville Jackson)]

Moving on … lets see if we can make a useful tree
The idea seems to be to bundle together daemons that are all needed for some area of work, but are not always needed, so they can be conveniently started and stopped as a bunch with one command.

I am going to try and setup a tree

• nfs-tree containing the nfs and rpc daemons needed to support client and server nfs operations

First make a tree

root@antix-init-diversity:/home/nevj# 66 tree create nfs-tree
tree: info: Created successfully tree: nfs-tree
tree: info: Permissions rules set successfully for tree: nfs-tree

Then check that it is there

root@antix-init-diversity:/home/nevj# 66 tree status
....
Name        : nfs-tree
Current     : no
Enabled     : no
Allowed     : root
Groups      : admin
Depends     : None
Required by : None
Contents    : None
...

Yep, it is there and empty. There are also the ‘global’ and’boot@system’ trees ( not listed).
and
the nfs-tree survives a boot, even if it is empty. Great.

Now install some packages
nfs-common … the nfs client
nfs-kernel-server … the nfs server
rpcbind … the remote procedure call daemon

Now , where are the daemons we have to start?
The packages will make sysvinit services, so if we look in /etc/init.d we find
nfs-common
nfs-kernel-server
rpcbind
so the services have the same name as the packages… thats nice… not all distros do that… sometime packages contain
We can look at those sysvinit scripts in /etc/init.d and we may get some clues about writing 66 frontends for these daemons, or we can just start with a minimal frontend and see what happens…
One of the issues here is going to be dependencies… rpcbind is a dependency of the two nfs daemons.
So lets try rpcbind first

[main]
@type=classic
@description="rpcbind daemon"
@version=0.0.1
@user=(root)
@requiredby = (#nfs-client #nfs-server )

[start]
@execute=(
    /sbin/rpcbind 
)

Note , I have defined 2 reverse dependencies, but commented them out because those daemons are not defined yet.

Now I want to start rpcbind in the nfs-tree

 root@antix-init-diversity:~# 66 -t nfs-tree start rpcbind
parse: info: Parsed successfully: rpcbind-log at tree: nfs-tree
parse: info: Parsed successfully: rpcbind at tree: nfs-tree
start: info: Initialized successfully: rpcbind
start: info: Initialized successfully: rpcbind-log
signal: info: Successfully started service: rpcbind-log
signal: info: Successfully started service: rpcbind

and it is running

root@antix-init-diversity:~# ps ax | grep rpc
 4265 ?        S      0:00 s6-supervise rpcbind-log
 4266 ?        S      0:00 s6-supervise rpcbind
 4273 ?        Ss     0:00 /usr/bin/s6-log -d3 n3 s1000000 /var/log/66/rpcbind
 4278 ?        Ss     0:00 /sbin/rpcbind

and it is in the nfs-tree

root@antix-init-diversity:~# 66 tree status
....
Name        : nfs-tree
Current     : no
Enabled     : no
Allowed     : root
Groups      : admin
Depends     : None
Required by : None
Contents    : rpcbind-log rpcbind
...

So that frontend is OK

Now the nfs client daemon .
Inspection of its sysvinit script in /etc/init.d reveals that it starts 3 daemons called rpc.statd, rpc.imapd, and rpc.gssd… but they are started optionally?

We have all the following installed from the nfs-common and nfs-kernel-server packages

/sbin/rpcbind

/sbin/rpc.gssd	 
/sbin/rpc.idmapd
/sbin/rpc.statd

/sbin/rpc.svcgssd
/sbin/rpc.mountd
/sbin/rpc.nfsd

The server needs rpcbind, statd, (optionally svcgssd) and nfsd services
The client needs rpcbind, statd, and optionally imapd and gssd services.
(Void has a client daemon called netmount but there seems to be to equivalent in Debian based systems)
If the server is nfsv4 statd is unnecessary.

rpc.statd deals with file locks across systems
rpc.gssd deals with security
rpc.idmapd deals with user and group id’s across systems

rpc.svcgssd deals with server side security
rpc.mountd deals with server side of the nfs mount procedure
rpc.nfsd is the server daemon

So, theoretically one should be able to setup a minimal nfs client by starting only rpcbind and statd. We will try that first, then deal wih the options.
An elementary frontend for nfs-client therefore is

[main]
@type=classic
@description="nfs client daemon(s)"
@version=0.0.1
@user=(root)
@depends = (rpcbind )

[start]
@execute=(
    /sbin/rpc.statd 
)

root@antix-init-diversity:~# 66 -t nfs-tree start nfs-client
parse: info: Parsed successfully: nfs-client-log at tree: nfs-tree
parse: info: Parsed successfully: nfs-client at tree: nfs-tree
start: info: Initialized successfully: nfs-client
start: info: Initialized successfully: rpcbind
start: info: Initialized successfully: rpcbind-log
start: info: Initialized successfully: nfs-client-log
signal: info: Successfully started service: rpcbind-log
signal: info: Successfully started service: nfs-client-log
signal: info: Successfully started service: rpcbind
signal: info: Successfully started service: nfs-client

adds it to the nfs-tree tree

Name        : nfs-tree
Current     : no
Enabled     : no
Allowed     : root
Groups      : admin
Depends     : None
Required by : None
Contents    : rpcbind-log rpcbind nfs-client-log nfs-client

So start it and see if nfs works

root@antix-init-diversity:~# 66 start nfs-client
signal: info: Successfully started service: rpcbind-log
signal: info: Successfully started service: nfs-client-log
signal: info: Successfully started service: rpcbind
signal: info: Successfully started service: nfs-client

Try a mount

~# showmount -e trinity
Export list for trinity:
/common 192.168.122.109,10.0.2.15,192.168.122.59,192.168.122.145,192.168.122.41,192.168.122.57
Yes /common has been exported to 192.168.122.109 which is the antixinitdev vm.

# mount -t nfs trinity:/common /mnt/trinity.common
# df
Filesystem       1K-blocks     Used Available Use% Mounted on
udev               3948688        0   3948688   0% /dev
tmpfs               794316     7532    786784   1% /run
/dev/vda1         51288544  9742784  38908040  21% /
cgroup             3971576        0   3971576   0% /sys/fs/cgroup
shm                3971576        0   3971576   0% /dev/shm
tmp                3971576       24   3971552   1% /tmp
trinity:/common 1116210176 93579264 965904384   9% /mnt/trinity.common

Yes , the mount works , so the only necessary daemon is statd.

Now , lets see if I can start the tree instead of the service

# 66 stop nfs-client
signal: info: Successfully stopped service: nfs-client

# 66 tree start nfs-tree
tree: info: Successfully started tree: nfs-tree

Yep, it does exactly the same thing… there are no additional daemons at the moment

Now, the big question, how can I setup the nfs-client service to optionally start the other daemons rpc.gssd and rpc.idmapd?
Sysvinit does it with a script. I think what is needed in s6-66 is an instantiated service.
I want it to always start rpc.statd, and to optionally also start rpc.gssd or rpc.idmapd.
I can see this much for a frontend nfs-client@

[main]
@type=classic
@description="nfs client daemon(s)"
@version=0.0.2
@user=(root)
@depends = (rpcbind )

[start]
@execute=(
    /sbin/rpc.@I
)

but , that will only start one daemon. I have to think about how to pass
more than one variable to an instantiated service.

[obarun]

@nevj

Now, the big question, how can I setup the nfs-client service to optionally start the other daemons rpc.gssd and rpc.idmapd?

It depends on what you mean by ‘optional’. How do you know whether or not you need these ‘extra’ services?

[nevj (Neville Jackson)]

@obarun

It depends on what you mean by ‘optional’. How do you know whether or not you need these ‘extra’ services?

I need idmapd if user names or groups differ between client and server machines.
I need gssd only if using RPSEC_GSS authentication
" The RPCSEC_GSS protocol, defined in RFC 5403, is used to provide
strong security for RPC-based protocols such as NFS."
So its an admin decision

I can easily start rpc.statd plus one other optional daemon

[start] @execute=(#!/bin/bash
/sbin/rpc.statd
 /sbin/rpc.@I
 )

That might be close enough or maybe I could pass some symbol and use a case statement

I am slowly getting the hang of 66. The biggest challenge is designing something other than starting every daemon . I guess that is why very few people ever use runlevels… have to think too hard.

I cant see at the moment how this fits in with starting the whole tree. I cant pass @I to the tree. Do i need a module maybe?

Thank you
Neville

[obarun]

@nevj

Sysvinit does it with a script

Can show us this script? It will be better to understand the needs here.

[nevj (Neville Jackson)]

@obarun

Can show us this script?

$ cat nfs-common
#!/bin/bash

### BEGIN INIT INFO
# Provides:          nfs-common
# Required-Start:    $portmap $time
# Required-Stop:     $time
# Default-Start:     S
# Default-Stop:      0 1 6
# Short-Description: NFS support files common to client and server
# Description:       NFS is a popular protocol for file sharing across
#		     TCP/IP networks. This service provides various
#                    support functions for NFS mounts.
### END INIT INFO

# What is this?
DESC="NFS common utilities"

# Read config
DEFAULTFILE=/etc/default/nfs-common
NEED_STATD=
NEED_GSSD=
PIPEFS_MOUNTPOINT=/run/rpc_pipefs
RPCGSSDOPTS=
if [ -f $DEFAULTFILE ]; then
    . $DEFAULTFILE
fi

. /lib/lsb/init-functions

# Exit if required binaries are missing.
[ -x /sbin/rpc.statd ] || exit 0

#
# Parse the fstab file, and determine whether we need gssd. (The
# /etc/defaults settings, if any, will override our autodetection.) This code
# is partially adapted from the mountnfs.sh script in the sysvinit package.
#
AUTO_NEED_GSSD=no

if [ -f /etc/fstab ]; then
    exec 9<&0 </etc/fstab

    while read DEV MTPT FSTYPE OPTS REST
    do
	case $DEV in
	    ''|\#*)
		continue
		;;
	esac
	OLDIFS="$IFS"
	IFS=","
	for OPT in $OPTS; do
	    case "$OPT" in
		sec=krb5|sec=krb5i|sec=krb5p)
		    AUTO_NEED_GSSD=yes
		;;
	    esac
	done
	IFS="$OLDIFS"
    done

    exec 0<&9 9<&-
fi

case "$NEED_STATD" in
    yes|no)
        ;;
    *)
        NEED_STATD=yes
        ;;
esac

case "$NEED_IDMAPD" in
    yes|no)	
        ;;
    *)
        NEED_IDMAPD=yes
	;;
esac

case "$NEED_GSSD" in
    yes|no)	
        ;;
    *)
        NEED_GSSD=$AUTO_NEED_GSSD
	;;
esac

do_modprobe() {
    if [ -x /sbin/modprobe -a -f /proc/modules ]
    then
        modprobe -q "$1" || true
    fi
}

do_mount() {
    if ! grep -E -qs "$1\$" /proc/filesystems
    then
	return 1
    fi
    if ! mountpoint -q "$2"
    then
	mount -t "$1" "$1" "$2"
	return
    fi
    return 0
}

do_umount() {
    if mountpoint -q "$1"
    then
	umount "$1"
    fi
    return 0
}

# See how we were called.
case "$1" in
  start)
	log_daemon_msg "Starting $DESC"

	if [ "$NEED_STATD" = yes ]; then
	    log_progress_msg "statd"
	    
	    # See if rpcbind is running
	    if [ -x /usr/sbin/rpcinfo ]; then
		/usr/sbin/rpcinfo -p >/dev/null 2>&1
		RET=$?
		if [ $RET != 0 ]; then
		   echo
		   log_warning_msg "Not starting: portmapper is not running"
		   exit 0
		fi
	    fi
	    start-stop-daemon --start --oknodo --quiet \
		--pidfile /run/rpc.statd.pid \
	        --exec /sbin/rpc.statd -- $STATDOPTS
	    RET=$?
	    if [ $RET != 0 ]; then
	        log_end_msg $RET
	        exit $RET
	    else
		if [ -d /run/sendsigs.omit.d ]; then
		    rm -f /run/sendsigs.omit.d/statd
		    ln -s /run/rpc.statd.pid /run/sendsigs.omit.d/statd
		fi
	    fi
	fi

	# Don't start idmapd and gssd if we don't have them (say, if /usr is not
	# up yet).
	[ -x /usr/sbin/rpc.idmapd ] || NEED_IDMAPD=no
	[ -x /usr/sbin/rpc.gssd   ] || NEED_GSSD=no

	if [ "$NEED_IDMAPD" = yes ] || [ "$NEED_GSSD" = yes ]
	then
	    do_modprobe sunrpc
	    do_modprobe nfs
	    do_modprobe nfsd
	    mkdir -p "$PIPEFS_MOUNTPOINT"
	    if do_mount rpc_pipefs $PIPEFS_MOUNTPOINT
	    then
	    	if [ "$NEED_IDMAPD" = yes ]
		then
	            log_progress_msg "idmapd"
		    start-stop-daemon --start --oknodo --quiet \
			    --exec /usr/sbin/rpc.idmapd
		    RET=$?
	            if [ $RET != 0 ]; then
        	        log_end_msg $RET
        	        exit $RET
                    fi
		fi
		if [ "$NEED_GSSD" = yes ]
		then
		    do_modprobe rpcsec_gss_krb5
	            log_progress_msg "gssd"

	            # we need this available; better to fail now than
		    # mysteriously on the first mount
		    if ! grep -q -E '^nfs[	 ]' /etc/services; then
		    	log_action_end_msg 1 "broken /etc/services, please see /usr/share/doc/nfs-common/README.Debian.nfsv4"
			exit 1
		    fi

		    start-stop-daemon --start --oknodo --quiet \
			    --exec /usr/sbin/rpc.gssd -- $RPCGSSDOPTS
		    RET=$?
	            if [ $RET != 0 ]; then
        	        log_end_msg $RET
        	        exit $RET
                    fi
		fi
	    fi
	fi
	log_end_msg 0
	;;

  stop)
	log_daemon_msg "Stopping $DESC"

	if [ "$NEED_GSSD" = yes ]
	then
	    log_progress_msg "gssd"
	    start-stop-daemon --stop --oknodo --quiet \
		    --name rpc.gssd
	    RET=$?
	    if [ $RET != 0 ]; then
                log_end_msg $RET
                exit $RET
            fi
	fi
	if [ "$NEED_IDMAPD" = yes ]
	then
	    log_progress_msg "idmapd"
	    start-stop-daemon --stop --oknodo --quiet \
		--name rpc.idmapd
            RET=$?
	    if [ $RET != 0 ]; then
                log_end_msg $RET
                exit $RET
            fi
	fi
	if [ "$NEED_STATD" = yes ]
	then
	    log_progress_msg "statd"
	    start-stop-daemon --stop --oknodo --quiet \
	        --name rpc.statd
	    RET=$?
	    if [ $RET != 0 ]; then
                log_end_msg $RET
                exit $RET
            fi
	fi
	do_umount $PIPEFS_MOUNTPOINT 2>/dev/null || true
	log_end_msg 0
	;;

  status)
	if [ "$NEED_STATD" = yes ]
	then
	    if ! pidof rpc.statd >/dev/null
	    then
	        echo "rpc.statd not running"
	        exit 3
	    fi
	fi

	if [ "$NEED_GSSD" = yes ]
	then
            if ! pidof rpc.gssd >/dev/null
	    then
		echo "rpc.gssd not running"
		exit 3
	    fi
	fi

	if [ "$NEED_IDMAPD" = yes ]
	then
            if ! pidof rpc.idmapd >/dev/null
	    then
		echo "rpc.idmapd not running"
		exit 3
	    fi
	fi

	echo "all daemons running"
	exit 0
	;;

  restart | force-reload)
	$0 stop
	sleep 1
	$0 start
	;;

  *)
	log_success_msg "Usage: nfs-common {start|stop|status|restart}"
	exit 1
	;;
esac
exit 0

It uses environment variables NEED_STATD and NEED_GSSD

That copy of the script came from Antix init diversity .
Runit ( in Void) has a completely different approach that seems to involve NetworkManager., and it has a separate service for every rpc.x daemon.

[nevj (Neville Jackson)]

@obarun

Can show us this script?

In Artix with s6-rc they only have services rpcbind-srv and statd-srv
Their run scripts are simple

trinity:[nevj]:/etc/s6/sv/statd-srv$ cat run
#!/bin/execlineb -P
fdmove -c 2 1
exec rpc.statd -F -d

trinity:[nevj]:/etc/s6/sv/rpcbind-srv$ cat run
#!/bin/execlineb -P
fdmove -c 2 1
exec rpcbind -f

That is about what I have in 66 at the moment, but I need to attend to arguments.
It looks like Artix have ignored idmapd and gssd. Maybe they dont exist in Arch?
No idmap is there

system/nfsidmap 2.6.4-1 [installed]
    Library to help mapping IDs, mainly for NFSv4

but it is a library , not a daemon.

There is no nfs-client service , but there is an nfs-server service… its run script is

trinity:[nevj]:/etc/s6/sv/nfs-server-srv$ cat run
#!/bin/execlineb -P
foreground { modprobe sunrpc }
foreground { modprobe nfs }
foreground { modprobe nfsd }
foreground { mountpoint -q /var/lib/nfs/rpc_pipefs }
redirfd -w 1 /dev/null
foreground { exportfs -ra }
foreground { rpc.nfsd -- 4 }
fdmove -c 2 1
exec rpc.mountd --foreground

[nevj (Neville Jackson)]

@obarun

better to understand the needs here.

I have experimented with various approaches.
The simplest and best seems to be to do what Void does with runit… a separate frontend for each of the rpc.x daemons and for ntpd.
Then you can either be selective, or start the whole tree and get everything.
I did get an instantiated service to work for one of the rpc.x daemons, but there are problems with arguments… it is not like a whole set of identical tty’s

I think nfs is a popular service … you might consider including it in your examples.

[obarun]

service · master · 66-service / Arch / nfs-utils · GitLab

Arch · GitLab

GitHub - mobinmob/void-66-services: 66 service frontends for voidlinux

[nevj (Neville Jackson)]

@obarun ,
Thanks, it seems Obarun has nfs configured. I must get the latest release… mine is old.
Arch frontends may not work in Debian. I will check.
The Debian based init diversity spins dont have nfs setup for 66.
and
I cant believe it, in that huge set of Void 66 frontends… there is no nfs?

Thank you
Neville

[nevj (Neville Jackson)]

@obarun

better to understand the needs here.

Can I nest one tree inside another ?
I tried to do this

 66 -t nfs-tree tree start nfsclient-tree

It started nfsclient-tree
but
it did not put it inside nfs-tree

# 66 tree status
Name        : nfsclient-tree
Current     : no
Enabled     : no
Allowed     : root
Groups      : admin
Depends     : None
Required by : None
Contents    : rpc.statd-log rpc.statd rpc.idmapd-log rpc.idmapd
              rpc.gssd-log rpc.gssd

Name        : nfs-tree
Current     : no
Enabled     : no
Allowed     : root
Groups      : admin
Depends     : None
Required by : None
Contents    : rpcbind-log rpcbind

I would like nfs-client-tree to appear inside nfs-tree.

Maybe I need to do something more than start nfs-client-tree with the option -t nfs-tree?
Maybe it is impossible.
Maybe I can use dependencies instead?

[obarun]

@nevj

Can I nest one tree inside another ?

Nope

@nevj

Maybe it is impossible.

yes

@nevj

Maybe I can use dependencies instead?

yes

# 66 tree admin -o depends=nfs-tree nfs-client-tree

Here nfs-client-tree will start after nfs-tree as it depens on nfs-tree

[nevj (Neville Jackson)]

@obarun

# 66 tree admin -o depends=nfs-tree nfs-client-tree

Here nfs-client-tree will start after nfs-tree as it depens on nfs-tree

It works.

root@antix-init-diversity:/home/nevj# 66 tree admin -o depends=nfs-tree nfsclient-tree
tree: info: Created successfully tree: nfsclient-tree
tree: info: Dependencies successfully managed for tree: nfsclient-tree
tree: info: Required by successfully managed for tree: nfs-tree

So it is possible to set dependencies between trees, as well as between individual services.

# 66 tree status
Name        : nfs-tree
Current     : no
Enabled     : no
Allowed     : root
Groups      : admin
Depends     : None
Required by : nfsclient-tree
Contents    : rpcbind-log rpcbind

I notice it is also possible to set reverse dependencies.

# 66 tree admin -h
66 tree admin [ -h ] [ -o depends=:requiredby=:... ] tree

I can not see that a reverse dependency would achieve anything extra.

Starting a tree:
I have discovered that doing
66 tree start nfs-tree
only starts services within the nfs-tree if they are enabled.
That is different from individual services, they can be started without being enabled.
I bet there is a good reason for this?

Everything works.
I can do

66 tree start nfsclient-tree
66 tree start nfsserver-tree

either or both.
The services within them have to be enabled
and
if I want the tree to start at boot, the trees also have to be enabled.
Dependencies look after the order of starting.

End of tree exercises. I think I understand trees now.

What we have found is that an init system with trees and dependency control enables one to avoid complicated startup scripts, like that sysvinit one above (reply 111).

[obarun]

@nevj

I can not see that a reverse dependency would achieve anything extra.

Let’s say you want to create another tree (let’s call it nfs-between) positioned between nfs-tree and nfsclient-tree. Without the requiredby field, you must declare nfs-between with a dependency on nfs-tree AND then modify nfsclient-tree to depend on nfs-between.

Now, with the requiredby field, you can declare nfs-tree as a dependency of nfs-between and specify nfsclient-tree as a requiredby for nfs-between. This way, you achieve the same result without needing to modify the nfsclient-tree declaration.

@nevj

That is different from individual services, they can be started without being enabled.
I bet there is a good reason for this?

Certainly, you may want some services in the tree to start at every boot (so you enable them) while keeping others disabled. For instance, you might have a tree that includes both the NFS service and CUPS. You need the NFS services to mount at every boot, but you may not need CUPS to start each time, even if your printer is shared through NFS.

[nevj (Neville Jackson)]

@obarun

you may want some services in the tree to start at every boot (so you enable them) while keeping others disabled.

I have already found an application for that.
I dont want to use Kerberos , so within nfsclient-tree , I leave rpc-gssd disabled.
Then when I start nfsclient-tree, it only starts rpc-statd and rpc-idmapd.
That is a neat way to get fine control

Only running the daemons that you need is a great way to build an efficient system.