Hi, > 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.
Don't worry about this, feedback are useful to improve the package. Thanks for taking the time to file bugs and followup, others probably just don't bother. > 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); (if I have to guess) please replace your /sbin/start-stop-daemon (wrapper) with a symlink that points to /lib/runit/start-stop-daemon.runit and try again the ssh service. Invoke-run, in the attempt of replace the sysv instance and avoid conflicts, calls /etc/init.d/foo stop. So when a wrapper is in place the service down itself. The call is skipped when /sbin/start-stop-daemon or /etc/init.d/foo are symlinks. > 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"?). great idea, thanks. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023476 in case you have better suggestion than 'lsof' > 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. Just try # update-service disable /etc/sv/default-syslog ( what it does is to remove the /etc/service/default-syslog link and creates /etc//service/.default-syslog then reinstall runit, the 'default-syslog' service will stay disabled until you purge 'runit' package or you remove the .default-syslog link > 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 I understand this, but please be more specific about 'Debian specific runit glue' : for stage 1 and 3, I have added switches to use alternative set of scripts. The intention was to experiment with native runit scripts[1], but you can also use it to avoid 'run_sysv_scripts'. For stage 2, you can skip run_svsv_scripts with a '/etc/runit/no.emulate.sysv' flag file; also, you can use '/etc/runit/default.runsvdir'. This one will basically prevent any automation (enable/disable) on a service by any debian package for runit services; restart of services linked in /etc/service during upgrades will still work. What else? (maybe you hope for less switches? I'm well available to discuss this, but please open a separate bug) > 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. Ok, I mentioned the new layout because I thought it could help to solve your issue but it looks like it's not the case, so let's stop discussing this here, otherwise the bug becomes hard to follow for readers. Now, back to the main subject: > 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?) From your point of view, yes; from the package(r) point of view, a missing link can be 1. the package that ships the runscript was never installed, so the link has to be created (the default in Debian is usually to enable a service at first install) 2. the package that ship the runscript is upgraded, and the admin removed the link (it want it disabled). In order to separate this two cases, and allow the admin to say "I want this to stay disabled and the setting to persist untill purge" the dot-link convention was created. > > 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. This is already the case: sysv uses "K-links" (like KNNname) to mark a service as disabled, while run_sysv_scripts only loop over "S-links". However this creates unexpected results: * I disable a native runit service, because I don't want the service to run (the service goes down) * then reboot the system * now I have an unsupervised instance of the service running So to really disable a service with runit, you'll have to disable both with runit and with sysv. This doesn't happen with other inits, so it will be a surprise for users. I personally can live with it, but there is a larger problem: what you're asking will shift maintainance burden from you to users that are using the "default proposed configuration": as a general principle, I think the onus should be on those who use a "non default configuration", as they are likely more expert. > 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 hope you understand (although you disagree) that there is no way I can keep together your particular needs and Debian policy + reasonable expectations of other occasional users by using the run_sysv_script interface. let's try another approach 1. let's say that I want to get rid of all the sysv compat layer (run_sysv_scripts + sysv bits in invoke-run), so I invent a sysv-2-runscript generator that for each sysv script in rc2.d creates a oneshot runit service that just do 'sv once' to itself and run /etc/init.d/foo start) [2]. 1.1 Now I have to place all generated runscripts in the service directory, so that they are available (by default right now it's /etc/sv); for sure, I don't want to overwrite a real runscript with this one, so if /etc/foo already exists, I skip to the next one. 1.2 Then I also want to enable each of those generated service, so I look at /etc/service, and if a foo|.foo symlinks does not exist, I create one that point to /etc/sv/foo. 1.3 also, I want to have a mechanism for replacing generated runscripts with real one in future, so maybe I can generate /etc/sv/foo.sysv scripts, but link (enable) as /etc/service/foo the runit packages will likely do 1.1 and 1.2 on each boot in stage 2 instead of calling run_sysv_scripts Problems: * you end up with /etc/sv/ populated with a lot of useless *.sysv services (you can maybe mitigate by creating empty dirs) * you have to mark services that you don't want to run with .dot-link in /etc/service For me: * I really hate to write to /etc/sv; everything under /etc/ is a conffile, so once it's written I can't remove nor update it forever For all: * a certain number of runsv process running almost for nothing * users will have to remove foo.sysv directories manually when a real foo service is provided I don't want to do this right now, but I'm open to some version of it (given that I have to test first if it works) when a runit-services[3] package that provides a certain number of native runscripts is available, so that the number of 'foo.sysv' created and the number of equivalent runsv process is relatively low. Overall I suspect there is a fundamental disagreement on what the package should do/automate by default: you want it to do as less as possible, I want it to produce an usable system (a generic reasonable setup) for a random user that is not a runit expert. I also would like to make it possible for expert user to override my "proposed default setup" with their own, but this require some effort and if the magnitude of the change is too large it can become impossible for me to support > > Maybe we should start from a statement of the particular problems > that need solving? Do you have such a document? > You mean basically what I'm doing with the runit packaging? Like what I plan to do and why? If that's what your asking, maybe a TODO file in the debian source directory? I can also try to briefly explain here if it helps Lorenzo [1] for example see https://github.com/cloux/runit-base/tree/master/etc/runit/bootup [2] it can be more complex playing with control override, but let's keep it simple for this example [3] for an early and incomplete work see https://packages.debian.org/experimental/runit-services
