Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1272093 > unrolled thread

Bug#1121617: runit: default-syslog not ready for incoming metalog package

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1121617: runit: default-syslog not ready for incoming metalog package Andrew Bower <andrew@bower.uk> - 2025-11-29 15:00 +0100
    Bug#1121617: runit: default-syslog not ready for incoming metalog package Lorenzo <plorenzo@disroot.org> - 2025-12-03 12:40 +0100
      Bug#1121617: runit: default-syslog not ready for incoming metalog package Andrew Bower <andrew@bower.uk> - 2025-12-03 20:50 +0100
        Bug#1121617: runit: default-syslog not ready for incoming metalog package Andrew Bower <andrew@bower.uk> - 2026-01-31 19:50 +0100
          Bug#1121617: runit: default-syslog not ready for incoming metalog package Andrew Bower <andrew@bower.uk> - 2026-01-31 20:30 +0100

#1272093 — Bug#1121617: runit: default-syslog not ready for incoming metalog package

[Multipart message — attachments visible in raw view] — view raw

Package: runit
Version: 2.2.0-6
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian@vv221.fr

Hi Lorenzo,

The default-syslog virtual service does not know about the forthcoming metalog
package[1]. I suggest a patch along the lines of the attached to prepare for
this implementation of syslog joining debian.

Thanks!

Andrew

[1] ITP #1109152 https://bugs.debian.org/1109152


-- System Information:
Debian Release: forky/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.17.8+deb14-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages runit depends on:
ii  libc6           2.41-12
ii  runit-helper    2.16.4
ii  sysuser-helper  1.6.0

Versions of packages runit recommends:
ii  runit-init  2.2.0-6

Versions of packages runit suggests:
ii  runit-services  0.10.0
ii  socklog         2.1.1+repack-1
pn  ucspi-unix      <none>
ii  xchpst          0.8.0~git20251026.d185632-1~ajb1
ii  zsh             5.9-8+b14

-- Configuration Files:
/etc/sv/default-syslog/check changed:
socklog-check && exit 0
unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type for socket' && exit 0
fuser /dev/log >/dev/null 2>/dev/null && exit 0 # psmisc is not essential+not available on Hurd
for service in rsyslog socklog-unix syslog-ng metalog busybox-syslogd inetutils-syslogd ; do
	sv u $service && sv check $service && exit 0
done
exit 1


-- no debconf information

[toc] | [next] | [standalone]

#1272492

Hi Andrew,

On Sat, 29 Nov 2025 13:51:33 +0000 Andrew Bower <andrew@bower.uk> wrote:
> Package: runit
> Version: 2.2.0-6
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: debian@vv221.fr
> 
> Hi Lorenzo,
> 
> The default-syslog virtual service does not know about the
> forthcoming metalog package[1].

default-syslog is scheduled for removal, although not in the next Debian
version of runit.

> I suggest a patch along the lines of
> the attached to prepare for this implementation of syslog joining
> debian.

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.

Best,
Lorenzo

[*]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

Best,
Lorenzo

> 
> Thanks!
> 
> Andrew
> 
> [1] ITP #1109152 https://bugs.debian.org/1109152
> 
> 
> -- System Information:
> Debian Release: forky/sid
>   APT prefers experimental
>   APT policy: (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.17.8+deb14-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
> LSM: AppArmor: enabled
> 
> Versions of packages runit depends on:
> ii  libc6           2.41-12
> ii  runit-helper    2.16.4
> ii  sysuser-helper  1.6.0
> 
> Versions of packages runit recommends:
> ii  runit-init  2.2.0-6
> 
> Versions of packages runit suggests:
> ii  runit-services  0.10.0
> ii  socklog         2.1.1+repack-1
> pn  ucspi-unix      <none>
> ii  xchpst          0.8.0~git20251026.d185632-1~ajb1
> ii  zsh             5.9-8+b14
> 
> -- Configuration Files:
> /etc/sv/default-syslog/check changed:
> socklog-check && exit 0
> unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol
> wrong type for socket' && exit 0 fuser /dev/log >/dev/null
> 2>/dev/null && exit 0 # psmisc is not essential+not available on Hurd
> 2>for service in rsyslog socklog-unix syslog-ng metalog
> 2>busybox-syslogd inetutils-syslogd ; do
> 	sv u $service && sv check $service && exit 0
> done
> exit 1
> 
> 
> -- no debconf information

[toc] | [prev] | [next] | [standalone]

#1272557

Hi Lorenzo,

On Wed, Dec 03, 2025 at 12:33:55PM +0100, Lorenzo wrote:
> On Sat, 29 Nov 2025 13:51:33 +0000 Andrew Bower <andrew@bower.uk> wrote:
> > The default-syslog virtual service does not know about the
> > forthcoming metalog package[1].
> 
> default-syslog is scheduled for removal, although not in the next Debian
> version of runit.
> 
> > I suggest a patch along the lines of
> > the attached to prepare for this implementation of syslog joining
> > debian.
> 
> 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.
> 
> Best,
> Lorenzo
> 
> [*]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

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

[toc] | [prev] | [next] | [standalone]

#1280335

> ===> /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;

I think for 'facility check' one might need to be able to define whether
we want an AND or OR relationship - the default 'sv' behaviour would be
to AND them together, whereas for some types of facility we may be
content with any one passing, so we could have something like:

  facility --any network

which would then have to explode into one 'sv' invocation for each
discovered provider and then OR the results together.

[toc] | [prev] | [next] | [standalone]

#1280337

I forgot the 'verb' in this example - adding now to avoid
any confusion:

On Sat, Jan 31, 2026 at 06:43:37PM +0000, Andrew Bower wrote:
> > ===> /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;
> 
> I think for 'facility check' one might need to be able to define whether
> we want an AND or OR relationship - the default 'sv' behaviour would be
> to AND them together, whereas for some types of facility we may be
> content with any one passing, so we could have something like:
> 
>   facility --any network

  facility --any check network
 
> which would then have to explode into one 'sv' invocation for each
> discovered provider and then OR the results together.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web