Package: runit Version: 2.3.0-2 Severity: normal X-Debbugs-Cc: Andrew Bower <[email protected]>, [email protected]
I'm about to close #1121671[1] by adding metalog to the list of syslogs in default-syslog service as a short term fix (since metalog package is already in unstable); however discussion on how to do/improve facilities is still open and can continue on this bug. Avaliable options (so far) are: * continue with default-syslog style shim services * change name to selected services group, by adding a shared suffix specific to each group (for example rsyslog.log, metalog.log ..) Then use in runscripts like 'sv check /etc/service/*.log' to express a dependency on a syslog service * "tag" services with a facility file and add a 'facility' command to check the status of services in the facility group ( and check that the dependency is running); NOTE: a patch for such facility program was attached to #1121671 this is also connected to runit-services's #1117993[2] bug (about checking network); I'm now prioritizing other issues but as soon as I've finished there I will write my reply here Best, Lorenzo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121617 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117993 recap of #1121617 below Lorenzo <[email protected]> wrote: > I can add 'metalog-log' [*] for now; if I add 'metalog' it won't work > when this is removed. > I intend to remove default-syslog in this cycle, just after renaming > other syslogs services; given that renaming a service in runit is non > trivial extra work I think is better to get the name right from the > start. [ snip] > > [*]or metalog.log if that's looks less ugly, the format of the 'log' > suffix is open for changes until other services are renamed. > Constrains are that it has to work with > 'sv start|check /etc/service/*.log' > and it has to be unique enough that there are no false matches > Andrew Bower <[email protected]> wrote: > Naming the runit service is one thing but in the first instance there > is no runit service so while default-syslog prevails it would need to > invoke a command that will launch the initscript, which is going to be > called 'metalog', regardless of what a future runit service directory > will do. 'service metalog X' will therefore do the right thing while > default-syslog still exists. > > But I would like to suggest considering an alternative approach to > launching facilities that doesn't involve impinging on the services > namespace - it is generally helpful, in my view, that service names > and application/package names tend to match and that their naming is > consistent across service integrations for the different init systems. > > The approach I prototyped, building on an earlier suggestion, but > using a process as the integration point (as you prefer!) rather than > a shell function, enables the existence of a facility to be flagged > simply by a marker file. I prototyped it in Perl but it could be > reworked as a shell script: ===> /usr/sbin/facility <=== #!/usr/bin/perl -w use strict; use File::Basename; use File::Glob qw(bsd_glob); my $svdir = $ENV{SVDIR} // "/etc/service"; my $command = shift or die "usage: $0 command facility..."; my %providers = map { map { basename(dirname($_)) => 1 } bsd_glob("$svdir/*/provides-$_") } @ARGV; exec ("sv", $command, keys %providers) if %providers; ===> Some typical facility provides <=== sv/connman/provides-network sv/dhclient/provides-network sv/network-manager/provides-network sv/rsyslog/provides-syslog sv/unbound/provides-named sv/wicd/provides-network ===> /etc/sv/acme/run <=== #! /lib/runit/invoke-run facility start network syslog || exit 1 exec chpst -u _acmed:_acmed -012 /usr/sbin/acmed -D
