Re: The 🐑 Shepherd gets a service collection

[Adam Faiz]

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 
shepherd.
 
> > Per-service logging is already implemented in the Shepherd, but could be 
> > streamlined to have a default logs directory:
> > https://skarnet.org/software/s6/s6-log.html#loggingchain
>
> 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.
 
> Thanks,
> Ludo’.