supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: "supervision@list.skarnet.org" <supervision@list.skarnet.org>
Subject: Re: Understanding the syslogd-linux Service Script
Date: Wed, 09 Sep 2020 08:01:53 +0000	[thread overview]
Message-ID: <ema5a2fc6e-1f09-4867-96af-516b74f59663@elzian> (raw)
In-Reply-To: <20200908184318.GB15636@cathexis.xen.prgmr.com>

>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


  reply	other threads:[~2020-09-09  8:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 16:53 Scott Colby
2020-09-08 18:15 ` Colin Booth
2020-09-08 18:43 ` Colin Booth
2020-09-09  8:01   ` Laurent Bercot [this message]
2020-09-12  6:42     ` Scott Colby
2020-09-12 10:08       ` Laurent Bercot
2020-09-12 10:14       ` Laurent Bercot
2020-09-12 17:59         ` Scott Colby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ema5a2fc6e-1f09-4867-96af-516b74f59663@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).