From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4578 invoked from network); 9 Sep 2020 08:01:57 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 9 Sep 2020 08:01:57 -0000 Received: (qmail 16548 invoked by uid 89); 9 Sep 2020 08:02:22 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 16539 invoked from network); 9 Sep 2020 08:02:21 -0000 From: "Laurent Bercot" To: "supervision@list.skarnet.org" Subject: Re: Understanding the syslogd-linux Service Script Date: Wed, 09 Sep 2020 08:01:53 +0000 Message-Id: In-Reply-To: <20200908184318.GB15636@cathexis.xen.prgmr.com> References: <20200908184318.GB15636@cathexis.xen.prgmr.com> Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudehgedguddvlecutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuggftrfgrthhtvghrnhepgfeufeeiffevleelkeettedtteetgfevvdfffeejudffjeeijeetfeduueekgeefnecuffhomhgrihhnpehsmhgrrhguvghnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth >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