On Fri, Oct 28, 2022 at 03:07:07PM +0200, Lorenzo wrote:
Hi,
> > 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?
Our expectations are apparently different. I would expect
/lib/runit/run_sysv_scripts to do what it says on the tin: run sysv scripts.
The only reason to skip a script (as far as I'm concerned) is that running it
would conflict with a runit service.
It's not just about starting services either: if /etc/sv/$name exists but the
service is not managed by runit (that is, /etc/service/$name doesn't exist),
and I start the service manually via the initscript, run_sysv_scripts will also
fail to stop it.
I understand that you're thinking of /etc/sv/ as "configuration", but in this
instance I would prefer configuration to be more explicit; if I want to disable
a service I'll make sure it can't be started (e.g. by modifying its
/etc/default file), not just refrain from creating a /etc/service/ symlink for
it.
If I just want to disable automatic startups, I'll create
/etc/service/servicename/down.
> > 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).
Example:
lrwxrwxrwx 1 root root 34 Feb 9 2009 /etc/service/atd ->
/var/lib/svn-checkout/services/atd
This isn't in /etc/sv, but it still means atd(8) is managed by runit.
> > 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..
Uh, what runtime directory? /etc/sv is currently a repository for
package-supplied and admin-provided service directories. Why would you move
that to /run, which is volatile?
> 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.
I'm sorry, you lost me completely (or maybe I lost you; see my example symlink
above).
> > 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
Yes.
For example, I have an atd service whose service directory is
/var/lib/svn-checkout/services/atd. This is symlinked into /etc/service.
run_sysv_scritps doesn't detect it as a runit-supervised service, because the
directory is different from /etc/sv/atd, and starts another instance via the
initscript.
I have many such services. I keep my runit service directories in Subversion
and have a checkout of the repository on all systems. I just symlink the
appropriate directory from the checkout into /etc/service if I want to run a
service.
I use /etc/sv to instantiate services that I have templates for; for example, I
have an openvpn runit service template, so I'll create /etc/sv/openvpn-foobar
and create a /etc/sv/openvpn-foobar/run ->
/var/lib/svn-checkout/services/openvpn-template/run symlink, then symlink
/etc/sv/openvpn-foobar into /etc/service (roughly).
This also means that another issue arises where, for example, I install openvpn
but instead of running it via the initscript, I run several runit services
(e.g. "openvpn-client1", "openvpn-server42"), and don't want to start the
Debian initscript at all. The proposed override-init.d mechanism could help
with this as well.
> > 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/):
Wouldn't it make sense to do that via a file in /etc/runit/boot-run? (It's what
I do on my own systems since you introduced /etc/runit/boot-run, fwiw.)
> after all runit is for supervise long run processes, while boot scripts are
> all oneshots.
Not all: for example, udev/eudev (as you also note) is a daemon that could also
be run supervised. But it's probably best to treat the script as a one-shot
anyway, and maybe replace the running udev/eudev with a supervised instance
later.
> This will make it harder to use oneshots for late boot scripts,
I'm sorry, but I don't see what you mean.
> 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?
I suppose it depends on how you do it; if you're out to get me, you'll find a
way. ;) (j/k)
Currently you run rcS.d scripts by default anyway; all I did was change the
place they were invoked from.
András
--
Mouse driver not found. Click to continue.
