Defining the workgroup objectives

Gerrit Pape pape at gmn.smarden.org
Sun Aug 14 15:33:18 UTC 2005


On Fri, Aug 05, 2005 at 12:44:08AM +0200, Sven Mueller wrote:
> Gerrit Pape wrote on 03/08/2005 20:32:
> > On Mon, Aug 01, 2005 at 06:23:59PM +0200, Sven Mueller wrote:
> >>Most importantly, it discourages use of syslog. Even with all its
> >>disadvantages, I definately prefer daemons using syslog over any other
> >>mechanism mostly because I (as the admin) can easily redirect the log
> >>to
> >>remote hosts, log different parts of the information to different logs
> >>(like log everything above debug to a file only kept for 24h while
> >>logging everything from warn upwards to some file kept for a month).
> >>With modern syslog implementations like syslog-ng I am able to divide
> >>or
> >>merge logs from different programs or syslog facilities as I want. I
> >>wouldn't be able to do so with daemons which always log to
> >>stdout/stderr.
> >
> > Sure you are, runit's logging facility provides all this, and
> > additionally it provides some more features such as automatic log
> > rotation, limiting logs by size or age.  See the svlogd(8) man page.
> 
> So svlogd graps daemon logging from their STDOUT/STDERR and magically
> adds information (capacity, loglevel)?

Of course not, syslogd is also not doing this, it gets facility and
priority encoded in <..> at the beginning of the log message.  The
socklog system log service is a simple program that translates this into
<facility>.<priority> strings to work conveniently with svlogd's pattern
matching.  If you can, install the socklog-run package on a Debian test
system, and look into /var/log/socklog/ to get a picture on how syslog
works with runit's logging facility.

> > And it discourages the use of syslog for a reason;
> I didn't say syslog is perfect. But recommending logging to
> STDERR/STDOUT instead isn't doing anything better than syslog. It might
> avoid security flaws, but from the other side of the fence (i.e. when
> you are looking for configurability instead of security first), syslog
> is definately better.

If there's anything you can configure in syslogd, but not with the runit
programs, I would like to know about it, AFAICS it's as configurable.
And having service daemons logging to stderr has more advantages: less
code in the daemon, easy logging for chroot'ed daemons to outside the
jail, separate logs for services with separate configurations,
reliability, still can be redirected to syslog (logger(1)).

> However: Should other services/daemons block because syslog isn't
> reachable? Believe it or not: The fact that syslog messages can get lost
> is by design (i.e. that is intended behaviour).

I prefer the different design decision; with runit's logging, a service
blocks when its corresponding log service is unable to write the logs to
disk, unless you tell it otherwise; logs are too important.

> I'm not talking about closing all FDs, just closing the standard
> STDIN/STDOUT/STDERR would be enough (on request per commandline option
> or by default with an option to disable that behaviour).

> If I ask a program to become a daemon (i.e. some --daemon commandline
> option or by that programs default), it should detach itself from the
> console it was started on.
> If I ask a program to stay in foreground (some --foreground option or
> that programs default), there is no need to detach and it could even be
>  counterproductive to try that.
> Actually, I would like daemons/services to act as the admin wishes, with
> either
> a) detach and background (become a classic daemon)
> b) stay in foreground, don't detach and fork childs as needed
> c) (rather exotic, but it might have its uses):
>    background but don't detach, preventing the shell from exiting,
>    but allowing more processes to be started from the same shell
> If at all possible, some standard commandline option to get each of
> these would be nice, but that is just a dream probably never becoming true.

I don't think such should be implemented in each and every service
program.  Use other tools to adapt the process state for them before
starting, such as chpst(8) or nohup(1), screen(1).

Regards, Gerrit.



More information about the initscripts-ng-devel mailing list