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.."