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
