>One thing that I forgot to mention here is that depending on the age of
>the libc this might not work properly as written. Newer libc's use
>datagram connections for syslog and because of that you need to
>hand-write the entire s6-ipcserver chain (since the s6-ipcserver
>entrypoint doesn't currently support passing the SOCK_DGRAM option to
>s6-ipcserver-socketbinder.
The syslogd-linux example is a pretty old one, I should probably
rewrite it. It will work as is with glibc, because glibc's syslog()
has a SOCK_STREAM fallback, so the s6-ipcserver chain is fine.
It will *not* work as is with musl, because musl's syslog() only
opens a SOCK_DGRAM socket. In that case, I recommend using socklog
instead:
http://smarden.org/socklog/
and the run script would just be: "fdmove -c 2 1 fdclose 0 socklog"
(you lose readiness notification but that's not a big problem for
socklog, which listens to /dev/log very fast, and the worst case is
the first log lines are sent to /dev/console)
Ultimately the syslogd service just needs to listen to the /dev/log
socket (as SOCK_DGRAM, as socklog does, or SOCK_STREAM, as s6-ipcserver
does) and translate the loglevel/priority in the log lines to human-
readable text and print them to stdout (as socklog or ucspilogd does).
The real work is done by the logger part, which is a s6-log process
that reads the translated log lines, matches them against some regexes
and logs them to various logdirs depending on what they match. The
s6-log script is the equivalent of syslogd.conf: that's where you
configure how to dispatch the syslog into different places.
--
Laurent
Received on Wed Sep 09 2020 - 08:01:53 UTC