From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: shepherd logging; console-agetty-service Date: Sat, 17 Feb 2018 19:02:27 +0100 Message-ID: <20180217190227.5eaf5622@scratchpost.org> References: <20180215114256.551-1-dannym@scratchpost.org> <20180215114742.663-1-dannym@scratchpost.org> <87r2pm8gfl.fsf@gnu.org> <20180215164135.188beed0@scratchpost.org> <878tbu8dat.fsf@gnu.org> <20180216215725.58607c8c@scratchpost.org> <87sh9zk2q1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en6oo-0007Yt-5M for guix-devel@gnu.org; Sat, 17 Feb 2018 13:02:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1en6oj-0002m7-6j for guix-devel@gnu.org; Sat, 17 Feb 2018 13:02:38 -0500 In-Reply-To: <87sh9zk2q1.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org Hi Ludo, On Sat, 17 Feb 2018 17:20:06 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Actually, could [shepherd] use syslog(3), which writes to /dev/log? As far as I understand the meaning overload in Linux, there's these: * syslog(2) - accesses the kernel log ringbuffer directly. glibc (rightly) pretends this doesn't exist. * /dev/kmsg - userspace access to read and write to the kernel log ringbuffer. It doesn't really work like a regular file. If you write(2) to it, that gets interpreted as a *line* of max length (1024 - 32) and this line gets added to the ringbuffer as a new message. Reading is weird too - but we won't use that directly. * syslog(3) - actually writes to /dev/log, a socket, which is usually listened to by a user-space process like syslogd. No kernel involved anywhere (well, I guess the BSD socket layer is involved...). If shepherd used /dev/log in the beginning that would mean that syslogd would have to be running before shepherd starts up. So syslogd would have pid 1, I guess ;) If we instead used /dev/kmsg, there would not really be a hard dependency. Linux takes care that the messages are printed to the console until a syslogd (maybe) appears, at which point syslogd will log the already-printed (to /dev/kmsg) messages to its output files. syslogd also fetches LATER messages from /dev/kmsg and appends them to its output files likewise as time goes by. So the UNIXy good-enough way would be for us to only use /dev/kmsg, the end= :) The complete way (which would avoid a hypothetical problem of overloading the ringbuffer with messages so we would lose some of them) would be to have shepherd start out using /dev/kmsg and switch over to using /dev/log when it's there (maybe use inotify and watch until /dev/log appears). Switch back to /dev/kmsg if /dev/log breaks again. Also possible would be to have shepherd provide /dev/log to user services and have shepherd proxy them to /dev/kmsg - that sounds like a real easy way to get into a cycle if we aren't careful - although it would be conceptually nicer. In fact, the Linux kernel could have done that transparently. They probably just didn't like the failover handling involved :) Also, I checked glibc misc/syslog.c vsyslog and they fall back to /dev/console - disappointing. They could have fallen back to /dev/kmsg ... But then if syslogd crashed nobody would re-enable console logging and it w= ouldn't be seen until syslogd started up again... it's actually starting to get complicated again :) > > Also a way of capturing stderr and stdout (and maybe even /dev/log) of = services > > would be nice. =20 >=20 > Yes. Though again capturing service stdout/stderr is kinda redundant > with what syslogd does. What I like in journald is the fact that it > unifies all logging facilities, and also connects them to service > management. Yeah, its nice nowadays after one gets used to it. In the end, it depends on whether one wants a system overview or a service-by-service overview. Older UNIX had lots of small programs working together in harmony to achieve one task that the user cared about. If you just watched the logs of one of them that wouldn't really help that much because you'd not see the parts the other guys did. And if you then watched *their* logs in an extra terminal or something you've have to manually cobble together the timeline in your head to make sense of what you are seeing. Sometimes some of the services involved were on other machines. So it was understandable that syslogd came to be a "global" thing (sometimes on a central server only). Nowadays with all the huge-ish services like dnsmasq which do everything on their own (DNS, DHCP, TFTP, kitchensink) just checking its log is enough. Not sure how (or whether) to unify both use cases. > Right, so we=E2=80=99d need shepherd to filter these and pass them through > syslog(3), which ensures correct message formatting. That=E2=80=99s what > > does apparently (thanks for the link!). Yeah.