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.