[systemd-devel] [RFC] systemd syslogd

Kok, Auke-jan H auke-jan.h.kok at intel.com
Fri Jun 17 13:44:09 PDT 2011


On Fri, Jun 17, 2011 at 11:53 AM, Bill Nottingham <notting at redhat.com> wrote:
> William Douglas (william.r.douglas at gmail.com) said:
>> For minimal distributions it is useful for systemd to have a
>> syslogd as this avoids the need for extra packages
>> (cron, rsyslog, syslog-ng, logrotate).
>
> My concern here is that this is the sort of thing that seems pretty
> clearly out of the general usage scope for systemd. Most all of the
> things that systemd includes are things that are useful on the majority
> of systemd systems, or are something that none of the existing versions
> are really best-of-breed yet (readahead). However, syslog daemons are
> all fairly well standardized, and I'm not sure we want to spend a lot
> of resources in systemd maintaining one. As such, if you really want a
> minimal syslog, it's probably best to handle as a separate project.
> (svlogd already exists, for example.)

I'm not sure I agree. At this point, given the output of systemd, a
logger seems like a really good idea. Having a base, safe, well
written and debugged logger that just does the basics (and right)
seems far more useful than telling everyone to find out how to
integrate a logger with systemd themselves (which I though was a
rather messy thing to do in the first place). Keeping it optional but
close to systemd itself allows us to make sure systemd logging
principles are well tested and provides a good path for other loggers
to use the same integration methods (setting up and taking over the
internal sockets etc.) as the default one.

It's also not trying to compete with other loggers - there's no remote
logging, no pattern matching or complex hooks etc., which seems like a
perfectly solid core logger starting point: boundaries are well
defined, it integrates perfectly with systemd (and not with any other
system - this logger won't work on a sysvinit machine, for instance).
Things like locking are taken seriously in the code William wrote.

I personally think that putting this outside of the systemd project
will not help anyone: neither alternative loggers, nor systemd.
Obviously it will have to be optional (like the readahead code already
is: compiled but not enabled by default), but others will surely
disagree, and there has to be space for a "gray" area here.

Auke


More information about the systemd-devel mailing list