Hi,
On Wed, 26 Oct 2022 18:26:02 +0200
Andras Korn <korn-debb...@elan.rulez.org> wrote:
> Package: runit
> Version: 2.1.2-50
> Severity: normal
>
> Hi,
>
> /lib/runit/run_sysv_scripts has this:
>
> for script in "$initdir/$rX"* ; do
> [ ! -x "$script" ] && continue
> path=$(realpath "$script")
> name=${path##*/}
> # Special case for wicd. Runscript is called "wicd-daemon",
> # to match binary package name.
> [ -d "/etc/sv/$name" ] && continue
> [ -d "/etc/sv/$name-daemon" ] && continue
> "$script" "$rcommand"
> done
>
> 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);
The runit service exists and is not enabled, so why one would want to
start a sysv instance instead?
To me 1. looks correct, can you make an example when it causes
unexpected/buggy results?
>
> 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).
>
> 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:
>
2. is an issue, especially because I'm thinking of moving the runtime
directory form /etc/sv/ --> /run/runit/sv/ : this move requires a
long transition period where both the old and the new path are
supported as runtime directories..
On the other hand I don't know if with systemd or Sysvinit is even
possible to boot the system with a custom path for services; I don't
want to make it unnecessary hard to do it with runit, but I think it's
reasonable to expect some effort on admin side for such setup.
> 1. have a /etc/runit/override-init.d/ directory. If $name exists in
> it, don't invoke the initscript in /lib/runit/run_sysv_scripts. This
> places the entire administration/configuration burden on the admin
> but is very simple to do, and easy enough for the admin to automate
> (e.g. your own service scripts can just create these files when
> they're first run).
I'm ok with adding this, but it's unclear to me if the above is
theoretical reasoning or you have an actual problem with your setup: in
case of the latter please add more detail to avoid the unhappy case
where the fix that i push doesn't solve your issue
>
> 2. pass the name of the /etc/runit/runsv directory that we expect to
> be used to /lib/runit/run_sysv_scripts somehow (for example, in an
> environment variable). This looks brittle (riddled with race
> conditions) and complicated to me, but it would require no effort
> from the admin.
>
> 3. invoke runsvchdir earlier during boot. This is problematic on
> systems where / is read-only before some initscripts are run.
>
I'm thinking of running boot scripts (rcS) in stage 1 unconditionally,
(or maybe only subjected to /etc/runit/override-init.d/): after all
runit is for supervise long run processes, while boot scripts are all
oneshots. This will make it harder to use oneshots for late boot
scripts, but will also avoid to break the boot sequence if one has,
let's say a /etc/sv/udev directory. Will this improve or worsen
your situation?
Lorenzo
> 4. [other kludges]
>
> András
>
