On Wed, Nov 16, 2022 at 02:03:14PM +0100, Lorenzo wrote:
> > > lsof /dev/log >/dev/null || exit 1
> >
> > I think
> >
> > fuser /dev/log >/dev/null 2>/dev/null || exit 1
> >
> > is more efficient, but there is a problem with both approaches: the process
> > that is listening on /dev/null may be invisible to us, because it may be
> > running in a different namespace.
>
> Thanks for the above: I didn't thought about using this service inside a
> container (when the logger is outside) and I agree it's a nice to have
> extension (assuming that you mean listening on /dev/log, otherwise I fail to
> understand what you are talking about)
Yes, sorry, my brain hit a bad sector there. /dev/log of course.
> > The only way to reliably determine whether there is a Unix server listening
> > on the /dev/log socket is to try to connect to the socket.
> >
> > One approach I can think of is to use
> >
> > unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type
> > for socket' || exit 1
> >
> > This creates a SOCK_STREAM socket and tries to connect it to /dev/log,
> > which will fail with EPROTOTYPE if there is a listening server (which will
> > use SOCK_DGRAM) and with ECONNREFUSED if not.
> >
> > Using unixclient would introduce a semi-esoteric dependency on ucspi-unix,
> > but it's a tiny package which is a good match for the runit ecosystem
> > anyway, so maybe it's acceptable.
> >
> > A more mainstream but much more heavyweight approach would be to use
> > socat(1) or netcat-openbsd with the -U option.
> >
> > Alternatively, socklog provides its own socklog-check, which does exactly
> > what is necessary, but the whole point of trying to detect whether *any*
> > syslog daemon is running is to avoid having to install a particular one
> > like socklog, so we probably shouldn't use it.
> >
> > OTOH, it's such a tiny program, and so unlikely to require changes ever,
> > you might even ship (a copy of) it as part of the runit package.
>
> I'm ok with ucspi-unix or socklog-check, but this can happen only after the
> bookworm release.
How about you make default-syslog/check use socklog-check or unixclient if they
are available, and fall back to the current heuristics if not? Something like
this:
#!/bin/sh
# note: only socklog exists as runit service in Debian right now
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
for service in rsyslog socklog socklog-unix syslog-ng busybox-syslogd
inetutils-syslogd ; do
sv u $service && sv check $service && exit 0
done
exit 1
If socklog-check and unixclient aren't installed, those commands will just fail
and the script will fall back to the next attempt.
The only way I can see this being worse than the current solution is if
searching PATH for executables is pathologically slow (e.g. due to an NFS
outage maybe).
> This bug can probably renamed as "default-syslog: useless inside a
> container", right ?
I don't think so; that wouldn't be accurate. It's only useless if the syslog
daemon and the check script run in different namespaces; if they run in the
same container, it works, and it also fails if check runs on the host and it's
the syslog daemon that's in the container (this should be rare though).
I'd call it "default-syslog: check for running syslogd not robust" or something.
András
--
Desk: A very large wastebasket with drawers.
