Hi Andras, Please follow up and let me know if my idea would solve this issue or at least improve the situation from your point of view: > > Checking for /etc/sv/$name and skipping initscripts if those > directories exist is wrong for two reasons: > > 1. /etc/sv/$name may not be symlinked into /etc/service (false > positive); > > 2. /etc/service may contain a symlink to a service directory for > this service that is elsewhere in the filesystem, not in /etc/sv > (false negative). > > As a minimum, I suggest the following: instead of /etc/sv/$name, > check for /etc/service/$name (and $name-daemon if necessary), and not > with "-d" but "-L" (because when running rcS.d, the target of the > symlink may only appear later, for example when a new filesystem is > mounted).
I propose the following: * patch runit-helper, update-service and /lib/runit/trigger_sv so that every (package provided) runit service is always represented in /etc/service/, either with a foo symlink (enabled) or with a .foo symlink (disabled). This way I (as a packager) can test /etc/service/ to know if a runscript exists in /etc/sv/. For users that have their own runscripts collection somewhere in the filesystem: they will enable their services by creating the foo symlink, and thay can have the sysv emulation skip certain services (let's say a bar service) by creating a /etc/service/.bar symlink. This would also prevent runit package (and runit-helper) to enable the bar service, if any /etc/sv/bar exists, because the logic in runit-helper and sv_trigger only test if the symlink (or dot-symlink) exists, but it doesn't care where it points. In any case runit/runit-helper only creates and remove links in the /etc/runit/runsvdir/default directory, so if you point runsvdir to another directory runit package doesn't enable or disable anything for you. * turn the run_sysv_scripts into a runit service that test for /etc/service/$name. Two main reason for this: 1. users can disable it, or change it at their will, while any change into /lib/runit/run_sysv_scripts is overwritten by the package, so users are forced to change stage 2 and create their own version of the script 2. when runit services are mixed with sysv scripts in the start sequence, the run_sysv_scripts can be RC-buggy, see #1024969 [1] for an example > > This is still imperfect during boot because /etc/service may point to > some directory that is not the one we'll switch to with runsvdir in > stage 2. I don't know what the best way of handling this (likely > rare) case is, but the following solutions come to mind: I think with the above solution this should be no longer a problem as we run the sysv emulation from within runsvdir. Hopefully this will make your "runit" life easier (?) > András > Lorenzo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%231024969
