Re: where to put helper to send stdout/stderr to syslog?

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

Hi Robert,

On Mon, 17 Jun 2019 15:12:27 +0200
Robert Vollmert <rob@vllmrt.net> wrote:

> > On 17. Jun 2019, at 14:45, Danny Milosavljevic <dannym@scratchpost.org> wrote:
> > 
> > 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 standard error,
> > they (and thus all shepherd services) should also already log to the
> > aforementioned syslog by default.
> > 
> > What is the use case you envision?  
> 
> It sure doesn’t seem like it. For that service, everything lands on
> /dev/console, and I even see some sshd messages there that
> don’t 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 AWFUL.

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 system
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 this
case)

If we had something like "logger" but with /dev/kmsg fallback, it would always
work whether or not syslogd was already started up (it would buffer the messages
into the kernel ring buffer /dev/kmsg until syslogd started up, at which point
syslogd would read out the kernel ring buffer and log the value, although with
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). 

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 something)

>I didn’t 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]