[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The 🐑 Shepherd gets a service collection

From: Adam Faiz
Subject: Re: The 🐑 Shepherd gets a service collection
Date: Fri, 17 Mar 2023 14:55:14 +0800

On 3/16/23 22:14, Ludovic Courtès wrote:
The main limitation of mcron for such thing is that it’s entirely
static: it reads a list of job specs upfront and then goes on to
schedule them.  There’s no communication protocol to talk to it and
add/remove jobs on the fly, which is what ‘at’ would need.
Would it be easier to add dynamic job spec support to mcron than adding a new 
command scheduler?

Regarding syslogd, I think a better approach is to tell the services to send 
their output to stdout and stderror,
so that logs don't depend on a separate logging service in the first place.

Yes, but:

   1. Some daemons include syslog support even today, sometimes optional,
      sometimes mandatory.

   2. Syslog is a bit more structured than just stdout/stderr output:
      there are facilities and levels, for instance—see syslog(3);
      syslogd provides interesting filtering capabilities.

Thanks, it looks like syslog is still important for structured logs.

Are there issues of logs sent to syslog being lost even when the syslogd 
service is specified as a requirement of services that use it?
If not, I think it's not necessary to add a syslogd implementation to the 
Per-service logging is already implemented in the Shepherd, but could be 
streamlined to have a default logs directory:

Interesting read, thanks!

Regarding the default logs directory, there’s /var/log already, or did
you mean something else?
I do mean /var/log, I felt like #:log-file in make-forkexec-constructor could 
be improved.
Rather than always having to specify the absolute log file path, #:log-file 
could just be set as #t and would then default to /var/log/$canonical-name of 
the service.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]