[systemd-devel] [RFC] systemd syslogd

Lennart Poettering lennart at poettering.net
Mon Jun 20 11:56:12 PDT 2011


On Fri, 17.06.11 14:53, 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 agree with Bill here.

I absolutely see benefit in introducing a new syslog implementation,
however I am not convinced that systemd is the right place for it. There
is a big number of features I'd like to see implemented in a syslog that
currently are not available in any free implementation (such as
SO_TIMESTAMP, SCM_CREDENTIALs, indexing, live view, unification of
syslog, audit, utmp/wtmp, kmsg and numerous other things), however if we
put all this together this will not be a small side project anymore but
be big enough to stand on its own feet. 

Right now systemd is primarily an init system. The auxiliary components
it includes are: a) relatively small AND b) really basic building blocks
of an OS AND c) something where there is no point in a competing
implementation/which will only be replaced in exceptional cases (but
possibly disabled frequently) AND d) something we want people to
standardize on.

While a full syslogd would certainly qualify for b) I don't think it
would qualify for a) -- if all the stuff I'd like to see would
implemented; and neither c) -- since enterpresey stuff will always
continue to use rsyslog or syslog-ng and rightly so; and neither d), for
the same reasons.

I think such a syslog daemon deserves its own project. We can of course
closely align the two projects -- but have it systemd itself? I'd prefer
not to.

I absolutely see benefit in more competition in the syslog area, and in
a syslog daemon that focusses on smaller devices and desktop systems,
but I am not convinced this should be in systemd itself.

I hope that's not too disappointing and I hope this won't stop you
continuing to work on your project (and to ensure you do, I'll review
your patch, in the hope that's helpful).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list