[systemd-devel] [RFC] systemd syslogd

[Kok, Auke-jan H]

On Mon, Jun 20, 2011 at 11:56 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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).

I don't think it's unreasonable. The hardest part is going to be to
un-internalize the code and make it build on it's own but against the
right parts from systemd where we have the need for it, and deciding
what to do with some of the internal systemd code we're borrowing
right now.

What makes it hard is the fact that we - especially from a MeeGo
perspective - have a clear perspective on how far we want to take this
feature wise, and tbh I don't think that we - at this point in time -
want to take it a lot further than the code currently sits. That makes
it a bit harder to say, start a fresh project and see if we can drum
the support up to grow this project to something larger. In the end,
it would be fairly low on the agenda to say, see if we can evendo
something about the utmp/wtmp stuff (we've got bigger fish to fry, a
lot).

This might just be a good time to reflect a bit, and just sit with
what we have. I think we'll use this code for a release in MeeGo for a
while and see what feedback and information we can get, perhaps in
it's current form, or as something that builds out of tree, we'll see
about that.

Auke