Gentoo seems to have a service called localmount. In order to get things running I changed this to mountall.They show the test-daemon being run under chpst with "-o 5". My /bin/sh test-daemon failed under this with/bin/sh: 0: 3: Invalid argumentI therefore changed the argument to allow 20 files, i.e. "-o 20"

As an ordinary user create a test-daemon, which puts out a time stamp!

It is documented that this currently (0.23) produces a failure message. This is a timing problem and the service will be started at the next runsvdir scan (if no "down" file), or try again, but see the warning in :-https://wiki.gentoo.org/wiki/Runit#Open … on_feature

In order to activate it a link would be added to /etc/service, although in ASCII this is typically a link to /etc/runit/runsvdir/default/. runsvdir will be scanning this directory and start services in there. This is the scan directory.

With Runit integrated under OpenRC it uses a separate scan directory /run/openrc/sv which is a tmpfs. OpenRC looks after putting links into this scan directory, using its own directory /etc/runlevels to keep track of what should be run. /etc/runlevels/default is perhaps the equivalent of /etc/rc2.d under SysVinit.

Whether OpenRC uses Runit or not is controlled by the start-up files in /etc/init.d

I suspect that it is best to leave distributed init.d files alone and create our own version, so that it won't be over-written during an upgrade. I will create my-bluetooth in init.d using the bluetoothd set-up I had created earlier. I based the dependencies on /etc/init.d/bluetooth.

Both of these services are running. As bluetooth started first and test-service, which was second has reported that it started, it might be worth making bluetooth depend on test-service! Unfortunately this does not work. I tried several methods to run openrc a bit later, but none worked until I hit on running it from rc.local after a sleep, while backgrounding it, so that it would not delay the boot.

Edit /etc/rc.local and add a line before the end so that it reads :-

(sleep 5 ; /sbin/openrc)&
exit 0

I haven't tried adjusting the sleep time from 5 seconds as it just worked, but maybe it could be less or on a slow machine it may need to be longer.

Although this is a crude hack to work around the start-up bug, it this seems to work ok. The service does start from the initial attempt, but it does not seem to be recorded correctly. The calling of openrc gets it to try and start it again, which tidies up the housekeeping IIUC.

All that was required to be set up was the init.d file. It is necessary to remove the dependency on runsvdir and the supervisor becomes supervise-daemon. It is also necessary to set up a pid filename as well as the command. Any arguments necessary to make the daemon remain in the foreground are also required. There is more detail in what can appear in the init.d file described in man openrc-run.