The officially official Devuan Forum!

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Runit and backwards compatibility

The Debian port of Runit has introduced some backwards compatibility, so that it can start services from /etc/init.d if they are not yet set up for Runit. To do this it uses the script /lib/runit/run_sysv_scripts.

This will look through the directory it has been passed (typically /etc/rcS.d and /etc/rc2.d) and it will run the scripts starting with "S" but only run them if they do not exist in /etc/sv. It uses rcS.d for stage 1 and rc2.d for stage 2. This seems reasonable, but there are problems.

I would have thought that all of the services in rcS.d would need to be started as the baseline for the system to be running and that they are probably not started by runsv.

As for stage 2, it starts the scripts in rc2.d if they are not in /etc/sv. It then starts runsvdir, which starts the services set up to run under Runit. There are two problems here. I suspect the /etc/sv is not the correct directory to check against, as the services here have not necessarily been enabled and indeed, people like me may not have finished setting up a service! I suspect that it may be better to check against /etc/service rather than /etc/sv, as those are the ones which have been enabled.

The other problem is that the sequencing may be wrong. So that if you have dbus set up to be run by runit and avahi has not yet been done, then avahi will fail as it will be started by run_sysv_scripts before runsv starts dbus. I am not sure what the answer might be for this.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: Runit and backwards compatibility

Interesting observation. I see that the run script for network-manager starts dbus first, and the one for lightdm starts dbus and elogind. So I guess if you write a new run script, you have to make sure you start anything that's needed first. It doesn't seem to be a problem that multiple scripts have 'sv start dbus' in them.

I think the obvious answer for now is that you gotta try it. See if you can break avahi and then fix it by editing /lib/runit/run_sysv_scripts to use /etc/service instead of /etc/sv.

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Runit and backwards compatibility

Thank you for your helpful observations.

I more or less copied the elogind run file from Void Linux. It starts :-

# elogind doesn't work right if it starts before dbus
sv check dbus >/dev/null || exit 1

which I assume will leave the elogind startup looping until dbus is running, while

sv start dbus

will hang until dbus is running. The latter sounds better. I suppose that that line could be included in an init.d script, although would that work if runsvdir has not been started yet?

Geoff

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Runit and backwards compatibility

I have now edited run_sysv_scripts to to use /etc/service instead of /etc/sv and it has not broken anything yet, but I will need to check what happens when I disable services under Runit, etc.

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Runit and backwards compatibility

Replacing /etc/sv with /etc/service in /lib/runit/run_sysv_scripts did seem to have the expected result that disabling a service in Runit caused it to be started via /etc/rc2.d on a reboot.

If this service then failed to start correctly because of a sequencing problem, then adding e.g. :-

sv start dbus

to the file in rc2.d also failed, probably because runsvdir had not been started yet,
causing the sv command itself to fail.

It was possible to get avahi-daemon to start correctly under Runit by adding the line :-

sv start dbus

to its run file and the sequencing then worked as expected.

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Runit and backwards compatibility

With the services which are running under runsvdir, I have tried indicating when they need another service to have been started. Thus I have :-
avahi-daemon, cups, ddclient, elogind
depending on dbus.

As mentioned earlier there seem to be 2 different versions of this

sv start dbus

or

sv check dbus >/dev/null || exit 1

I have seen messages in the logs where dbus fails to start correctly the first time, only to start correctly 1s later, thus :-

2022-03-11_18:11:17.33232 warning: dbus: unable to open supervise/ok: file does not exist
2022-03-11_18:11:17.34982 Found user 'avahi' (UID 104) and group 'avahi' (GID 111).
2022-03-11_18:11:17.34983 Successfully dropped root privileges.
2022-03-11_18:11:17.34983 avahi-daemon 0.8 starting up.
2022-03-11_18:11:17.34983 dbus_bus_get_private(): Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
2022-03-11_18:11:17.34983 WARNING: Failed to contact D-Bus daemon.
2022-03-11_18:11:17.34983 avahi-daemon 0.8 exiting.
2022-03-11_18:11:18.33051 ok: run: dbus: (pid 2007) 1s
2022-03-11_18:11:18.33159 Found user 'avahi' (UID 104) and group 'avahi' (GID 111).
2022-03-11_18:11:18.33163 Successfully dropped root privileges.
2022-03-11_18:11:18.33173 avahi-daemon 0.8 starting up.
2022-03-11_18:11:18.33227 Successfully called chroot().

This type of message is intermittent and was produced with

sv start dbus

I will try it with

sv check dbus >/dev/null || exit 1

and see if that works better. I assume that this might suppress the warning message if it is redirected to /dev/null, but I will need to look out for the daemon failing and then trying again 1s later and succeeding.

Lorenzo

Member

Registered: 2020-03-03

Posts: 46  

Re: Runit and backwards compatibility

Hi Geoff 42,

The two problems that you identified are somehow real bug in the runit package, but

Replacing /etc/sv with /etc/service in /lib/runit/run_sysv_scripts did seem to have the expected result that disabling a service in Runit caused it to be started via /etc/rc2.d on a reboot.

I don't think this is a correct solution: especially with runit as init, if a user disables a service, it should not start. A native disabled service on a runit system should definitely not start automatically at boot (even with a sysv instance); it may be different in a sysv system that uses runit as a service manager.
So the bug here is that for now, there is no tool for the sysadmin to tell the system to disable a service with runit and also with sysv (and any other init supported): it would be a job for update-rc.d, I already sent patches but they were rejected for several reason and the bug report is stuck. I plan to fix this in runit 2.1.2-46 or maybe -47.

I suspect the /etc/sv is not the correct directory to check against, as the services here have not necessarily been enabled and indeed, people like me may not have finished setting up a service!

just use 'servicename-wip' and keep it disabled by default untill your service is ready for use.

As mentioned earlier there seem to be 2 different versions of this

sv start dbus

or

sv check dbus >/dev/null || exit 1

According to my testing

sv start dbus  ||  exit 1

will do it, or alternatively you can

sv up dbus  &&  sv check dbus  ||  exit 1

but

sv check dbus >/dev/null || exit 1

will not always work as expected, because if the requested status is down sv check can exit 0,
so before you use check make sure to set the wanted status

Also, of all dependencies, dbus is not easy to get it right, because there is a relevant time since when it reports itself as 'up' and when
it actually finishes its initialization, so you need a check file, see
https://salsa.debian.org/runit-team/run … dbus/check

Also if you use dbus from there be aware that the exec line of dbus should be

exec dbus-daemon --system --nofork --nopidfile 

without chpst. It used to work with chpst but it's broken since a recent upgrade in Debian

The other problem is that the sequencing may be wrong. So that if you have dbus set up to be run by runit and avahi has not yet been done, then avahi will fail as it will be started by run_sysv_scripts before runsv starts dbus. I am not sure what the answer might be for this.

Correct: my answer is to make native runit services available all at once, in a runit-services[1][2] package, especially services that are involved in a chain of dependency. Again, right now I'm stuck there too, but I hope it will get a sponsor in future. If not I may also consider a Devuan package if Devuan Devs allow me.

[1] https://bugs.debian.org/cgi-bin/bugrepo … bug=986656
[2] https://salsa.debian.org/runit-team/run … /tree/next   (watch out, very experimental!)
[3] https://bugs.debian.org/cgi-bin/bugrepo … ug=1005309

Lorenzo

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Runit and backwards compatibility

Lorenzo!

thank you for your detailed response to my comments.

Before I get onto the details, might I ask about the salsa.debian.org URL,
as it opens, but does not display the actual content for me. Does it need me to create an account?

The situation with /etc/sv versus /etc/service is interesting and may depend on your
point of view. I am currently working through services and converting them from SysV to Runit.
Therefore, I would like the SysV service to keep running until I have the Runit version correctly
set up, in which case the use of /etc/service seems to work better for me. But I accept your
point about disabling a service, once everything is set up.

just use 'servicename-wip' and keep it disabled by default untill your service is ready for use.

I'm sorry, but I don't understand the bit about 'servicename-wip'. (Ah! does 'wip' stand for 'work in progress', so that it doesn't match the real name?)

As for a dependency, I see that the Man page for sv says that sv start is the same as sv up but that it waits for the command to take effect, calling the check script if present. This would seem to mean that sv start dbus is the same as sv up dbus && sv check dbus. I assume that the || exit 1 will cause Runit to recognise that the dependency has not started and retry later (1s ?).

I have used the run line :-

exec dbus-daemon --system --nofork --nopidfile

and have a check file :-

#!/bin/sh
exec dbus-send --system / org.freedesktop.DBus.Peer.Ping > /dev/null 2> /dev/null

I may have copied these from Void Linux.

Thank you for all of your work on Runit.

Geoff

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Runit and backwards compatibility

It would appear that the links to, e.g. https://salsa.debian.org/runit-team/run … /tree/next do not work from Pale Moon,
but do work from Falkon.

Edit: and it works in Chromium.

Geoff

Last edited by Geoff 42 (2022-03-14 11:54:34)

Lorenzo

Member

Registered: 2020-03-03

Posts: 46  

Re: Runit and backwards compatibility

(Ah! does 'wip' stand for 'work in progress', so that it doesn't match the real name?)

Exactly

As for a dependency, I see that the Man page for sv says that sv start is the same as sv up but that it waits for the command to take effect, calling the check script if present. This would seem to mean that sv start dbus is the same as sv up dbus && sv check dbus. I assume that the || exit 1 will cause Runit to recognise that the dependency has not started and retry later (1s ?).

Yes, that's the idea.

and have a check file :-

#!/bin/sh
exec dbus-send --system / org.freedesktop.DBus.Peer.Ping > /dev/null 2> /dev/null

the one that I linked in salsa.debian.org does

#!/bin/sh

test -S /var/run/dbus/system_bus_socket && exit 0

exit 1

both are fine according to my testing

Thank you for all of your work on Runit.

 

Reports from tinkerers and users are very helpful to improve the package but sadly I get very few on Debian..
Also I read this forum rarely, so consider to use

reportbug runit

or send a ping if you want me to join a discussion

Lorenzo