On Wed, Nov 02, 2022 at 01:45:24PM +0100, Lorenzo wrote:
Hi,
> Am I correct that this is not a regression introduced with recent changes to
> runit? [relevant to understand if I have to revert something in case I can't
> fix this before the freeze]
Yes. I just started using the default config files (/etc/runit/1 mainly) that
you ship, and noticed this problem due to that.
> Anyway, let me clarify this one first:
> >
> > 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?
> >
>
> A. package supplied
> B. admin-provided
> C. runtime directory ( the directory that is actually
> monitored by a runsv process when the service is enabled)
>
> with the current setup, A,B and C are overlapped in /etc/sv/: what I plan to
> do is to separate these in 3 different path, like
>
> A. /usr/share/runit/sv/ (package supplied runscript, source format -->
> symlinks are missing)
> B. /etc/sv/ (reserved for local admin provided runscript)
> C. /run/runit/sv/ (runtime copy of services)
>
> At system boot (see TODO comment in stage 2) a specialised cpsv(8) tool is
> used to copy relevant runscript in C; when a 'name' runscript exists both in
> A and B, the copy in B takes precedence. C is kept in sync with A and B
> during runtime thanks to a trigger that is activated when a package that ship
> a service is installed/ removed/ upgraded. To pick up changes to B, the local
> admin will have to call cpsv (either with --sync or with -a).
>
> Now, cpsv is still WIP, and I can make A and C somehow configurable, and make
> run_sysv_script behave consistently with cpsv, but is this really usefull?
My first impression is you're trying to solve what is not a problem, and
introducing unneeded complexity, where part of runit's appeal (at least for me)
is its simplicity and straightforwardness. You're building extra layers around
runit so that people who are familiar with runit per se aren't able to use the
Debian runit packages without jumping through hoops. There may be good reasons,
but personally, I don't like this direction.
I would just as soon manage my /etc/service/* symlinks without any package
automation.
That said, I would be grateful for ways of getting rid of the following
annoying behaviours:
1. openssh ships its /etc/sv/ssh directory, which gets symlinked to
/etc/service during installation, but which never worked for me (unfortunately
I didn't investigate, just replaced the symlink with one to my own
/var/lib/svn-checkout/services/ssh);
2. a default-syslog service is created by something, and all it does on my
systems is sleep indefinitely (I use socklog as my syslogd, but have my own
service directory for that as well, and its name is just "socklog", so the
magic "check" script won't pick it up -- and neither will it pick up a syslogd
that is not managed by runit. Maybe just try to see if something is listening
on /dev/log in "check"?).
If I could override /etc/sv/ssh with my own directory (e.g. if "B" were a
configurable list of locations in order of precedence), that would solve #1.
If it were possible to disable the "default-syslog" service conclusively,
permanently, by creating something somewhere during installation, or writing a
line into a file, that would be great.
Being able to opt out completely of all Debian specific runit glue would be
even better; I accept that it's convenient for new or casual users, but for me
in particular it's mostly just frustrating due to it being different from
upstream runit, which I started using in around 2004 (switching to it from
daemontools).
> A: with the new layout, what would be the reason for you to checkout your svn
> somewhere else than /etc/sv/ ?
1. /etc is for configuration. /var/lib/svn-checkout/services is not
configuration; it's more like your /usr/share/runit/sv (except it's not shipped
by a package, but it might as well be).
2. I see /etc/sv as a place to instantiate template-based services; like
systemd has openvpn@foo, I have /etc/sv/openvpn-foo, whose run script is a
symlink to my svn checkout's openvpn-template/run (and the script infers what
openvpn config to use based on the "-foo" suffix of the runit service name).
Mixing local instantiations with upstream svn content would be hard to maintain
(e.g. "svn status" output would be cluttered).
> C: to some extent is already configurable, because I need that for the
> transition and I want to support user services (in /home/ ), but I'm not sure
> there is a reasonable use case beyond that..
FWIW, user-template is another such service I instantiate separately for each
user who needs to be able to have their own runit services. But you lost me
again: what is already configurable to some extent?
> > > > 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).
>
> Thinking more about this, I suspect the problem is caused by an inconsistent
> service layout: You have B and C= /var/lib/svn-checkout/services/ but in some
> special cases (multi-instance openvpn) you have B=
> /var/lib/svn-checkout/services/ and C= /etc/sv/
I'm sorry, but I don't see how it's relevant where those symlinks are pointing.
> Having links in /etc/service/ that point to different locations makes
> heuristic on my side really hard and error prone:
For the heuristics, I think all that matters is whether /etc/service contains a
symlink for a service or not; where that symlink points doesn't matter.
> I think is reasonable to ask the admin to use a unique path for C.
I'm still not convinced a separate path for C is needed.
> I am ok with some of the changes you suggested[1], but I have to support the
> case where a runit service exists and it's disabled:
>
> > 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.
>
> My concern is more with /etc/service/, right now to represent a disabled
> service you have
>
> 1. missing link in /etc/service (implicit)
I think this is pretty explicit. If there is no symlink, the admin doesn't want
runit to manage that service.
> 2. dot-link, like /etc/service/.name (explicit)
I don't see the need for this mechanism at all (which is not to say there isn't
one).
> I don't consider /etc/defaults/name or the down file a proper way to mark a
> service as permanently disabled: the former is not transparent to runit and
> is also a RC but for Debian policy [2]; the latter has a cost in term of a
> runsv process running for nothing.
I agree in principle with the point about the runsv process running for nothing
(although in practice, few such processes can be expected to exist and their
resource usage is negligible).
To permanently disable a runit service I would just remove the pertinent
symlink from /etc/service. If there were no further compelxity with runit
trying to emulate SysV init, that would be that. With all the effort to be
somewhat compatible with SysV init and emulate some of its functionality,
you've painted yourself into a corner where you need yet more complexity to
give the admin a way to also explain to the emulation logic that while a
runit-supervised instance of a service isn't being run, the SysV emulation
should also refrain from starting an unsupervised instance via the initscript.
I don't agree with the arguments in [2], but SysV init is so fundamentally
broken that it's probably impossible to fix all its problems with just glue; in
particular, service dependencies can't be meaningfully handled even in theory
(if a dependency stops, there is no way for the dependent service to be stopped
also; it would need its own logic to handle this case and exit when necessary).
So, while I would probably choose a different set of compromises than Debian
policy, my solution would be just as imperfect. If Debian policy discourages
/etc/defaults as a means of disabling a service, that's fine.
For us, IIUC, the important question now is how to handle explicitly disabled
services in the runit SysV emulation, right? I'd be fine with the following:
1. if no /etc/service/foo symlink exists, the admin explicitly disabled runit
management of service foo. (No argument there, I think?)
2. to also explicitly disable SysV instances of foo being started, use whatever
mechanism the sysvinit package provides to disable the sysv-style service
startup as well, and have the runit SysV emulation honour this.
Maybe we should start from a statement of the particular problems that need
solving? Do you have such a document?
András
Ps. I appreciate all the work you're doing on the runit packages. Please don't
take my occasionally vehement disagreement with some of your ideas personally.
--
Emacs is a decent enough operating system, but it lacks a good editor.
