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]
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?
A: with the new layout, what would be the reason for you to checkout
your svn somewhere else than /etc/sv/ ?
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..
(looking for comments/ reason for not doing the above)
> > > 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/
Having links in /etc/service/ that point to different locations makes
heuristic on my side really hard and error prone: I think is reasonable
to ask the admin to use a unique path for C.
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)
2. dot-link, like /etc/service/.name (explicit)
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'm still open to other suggestions.
Lorenzo
[1] for rcS: only check for /etc/runit/override-init.d/
for rc2: [ -e /etc/runit/override-init.d/name ] && continue
[ -L /etc/service/name ] && continue
# remove name-daemon tests, useless
[ -d /etc/sv/name ] && continue # /etc/sv/ path may be
# configurable with some flag file, still have to
# understand if is useful
/etc/init.d/name start
[2] https://www.debian.org/doc/debian-policy/ch-opersys.html,
paragraph 9.3.3.1. "An older practice, which should not be used.."
