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

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

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

Edit: and it works in Chromium.

Geoff

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.

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

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

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.

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

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

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

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 :-

This type of message is intermittent and was produced with

I will try it with

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.

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.

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

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.

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.