From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: where to put helper to send stdout/stderr to syslog? Date: Mon, 17 Jun 2019 16:45:56 +0200 Message-ID: <20190617164556.6615d413@scratchpost.org> References: <20190617144549.3430003f@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/9NKzdyvwv_NxRktZA_mg73h"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50137) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcsto-0007CN-TM for guix-devel@gnu.org; Mon, 17 Jun 2019 10:46:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hcstn-0008JU-EH for guix-devel@gnu.org; Mon, 17 Jun 2019 10:46:20 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:59298) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hcstl-0008Ds-DS for guix-devel@gnu.org; Mon, 17 Jun 2019 10:46:19 -0400 In-Reply-To: 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: Robert Vollmert Cc: guix-devel@gnu.org --Sig_/9NKzdyvwv_NxRktZA_mg73h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, On Mon, 17 Jun 2019 15:12:27 +0200 Robert Vollmert wrote: > > On 17. Jun 2019, at 14:45, Danny Milosavljevic = wrote: > >=20 > > But doesn't shepherd already log to /dev/kmsg and/or /dev/log (so that = ends up > > in syslog)? Since exec-command&co keep the standard output and standar= d error, > > they (and thus all shepherd services) should also already log to the > > aforementioned syslog by default. > >=20 > > What is the use case you envision? =20 >=20 > It sure doesn=E2=80=99t seem like it. For that service, everything lands = on > /dev/console, and I even see some sshd messages there that > don=E2=80=99t make it to syslog... Hmm, could you file a bug report to bug-guix@gnu.org about that? The intent was that shepherd logs its own stdout & stderr to syslog, and by process attribute inheritance every service does, too--except when a service doesn't want to, of course. I was figuring that maybe the process name that was logged was wrong in your case or something--but not logging at all is A= WFUL. I've read modules/shepherd/comm.scm now and that's definitely a lot more complicated than I remember. I think that duping loses the custom guile ports we had set up (it's obvious in retrospect). Using "logger" for everything has the additional wrinkle that when the syst= em shepherd starts up, syslogd is not started up yet. The "logger" executable has NO fallback to /dev/kmsg in order to log into the kernel ring buffer in the mean time. (shepherd does have it--but that doesn't help us much in th= is case) If we had something like "logger" but with /dev/kmsg fallback, it would alw= ays work whether or not syslogd was already started up (it would buffer the mes= sages into the kernel ring buffer /dev/kmsg until syslogd started up, at which po= int syslogd would read out the kernel ring buffer and log the value, although w= ith a strange prefix). Another possibility is to implement socket activation in shepherd, make it = claim /dev/log and start syslogd once /dev/log is first accessed (on demand).=20 Shepherd socket activation would still have to take care of (unintended) service dependency cycles that could arise, though. In any case, it will end up using something like your procedure, so I'm OK = with adding a variant of it. (I don't like the name much--maybe rather "with-syslog-console" or somethin= g) >I didn=E2=80=99t figure out how else to refer to it (string-append #$inetutils "/bin/logger") or something like that. As an aside, interesting that inetutils' logger doesn't use glibc's openlog. inetutils wrote their own implementation. glibc's openlog doesn't fall back to /dev/kmsg either. Grr. --Sig_/9NKzdyvwv_NxRktZA_mg73h Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl0Hp6QACgkQ5xo1VCww uqVArQf8Dw2JAXkiXrcNYXHCFbNwTh431Q13wVdf/Kc5MzKaI0ii1w0Rb5V3sA5o DOH/tM83oEU7/DUWumKIjJe7P7HYk1BrdASbfKV6IZHh90QO6hT/l/M6ik1SItcv cKTouahafVUIKgSeGN6SIR0brxMYmRdg7r+LxBoRjdvUimjr7hhMZLd9CE6sy10u ASMxFZRErfcVPSiuKndaTQkGv/YAXhbrEyzIbf+sObApfHo9SUvnrINtLLNBqlYQ 3vsEYhd+5jIoN/OKDQbAbHJjIkHotbZmYEbz1u5OFn22Xu60s1u04xuLcUYtO6Ml Mk4mszK3JoYVzChMMigMrXwsAH4tHA== =O4HM -----END PGP SIGNATURE----- --Sig_/9NKzdyvwv_NxRktZA_mg73h--