replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]

Kay Sievers kay at
Wed Oct 10 20:02:26 UTC 2012

On Wed, Oct 10, 2012 at 9:49 PM, Simo Sorce <simo at> wrote:
> On Wed, 2012-10-10 at 21:44 +0200, Kay Sievers wrote:
>> On Wed, Oct 10, 2012 at 9:31 PM, Konstantin Ryabitsev
>> <icon at> wrote:
>> > On Tue, Oct 9, 2012 at 5:24 PM, Lennart Poettering <mzerqung at> wrote:
>> >> I am not generally against adding time-based rotation, but really, this
>> >> is much less of a "necessity" than other things the journal provides,
>> >> which syslog does not: for example per-service rate limits, and
>> >> unfakable meta-data for log messages. I mean, really, how can we ship
>> >> a syslog where every random user can fake messages, say they are from a
>> >> privileged process and offer no way how to detect that?
>> >
>> > I think you overestimate how much a sysadmin cares about fake
>> > messages. The thing that's really important to a sysadmin is to make
>> > sure that none of the REAL messages are lost. If someone fakes root
>> > login entries by using something as trivial as "logger", I can easily
>> > establish they are fake by looking at auditd logs. And then I would
>> > *really* make that user regret their actions by using blunt
>> > cryptanalysis tools.
>> >
>> > So, it's not accurate to say that we don't currently have ways to detect that.
>> That works only for very very few of the logged messages, and it is a
>> good example how things should really not be designed or work today.
>> We need one source of system log and not a bunch of daemons with all
>> overlap but still have only parts of the picture, store their own
>> stuff all over the place.
>> Manual matching between the different data sources can sometimes be
>> used to find out what was really going on, but that's really not good
>> enough today.
>> The journal daemon uses similar close-to-the-kernel properties to
>> establish trust in logged messages, and in the future it is planned
>> that it will also rad all audit messages directly. The audit daemon
>> will then mostly be a policy execution engine for (rather exotic)
>> requirements like "crash the box if the message does not go to disk".
> It seem your intention is to make the journal so much better that it
> will be the preferred choice (and indeed the default).

The journal is nothing really to choose, it's a mandatory core part of
the operating system, systemd needs it itself, and it always runs.

A running syslog daemon always gets its data forwarded only from the
journal daemon. Syslog is by fact today already an "add-on", and not a
required component, it is just installed by default today. I don't use
or run syslog on any of my boxes since quite a while.

> So make it really better and support time-based rotation. You don't need
> to make time-based rotation the default, but you'll make a lot of people
> happy to have the option.

I really don't mind someone implementing a "maximum retention policy"
for the journal, surely sounds useful for some setups, but I'm
personally not really interested in implementing it.


More information about the devel mailing list