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

[Lennart Poettering]

On Tue, 09.10.12 07:53, Matthew Miller (mattdm at fedoraproject.org) wrote:

(Not that I actually already wanted this discussion now, but heck...)

> On Tue, Oct 09, 2012 at 10:58:45AM +0000, "Jóhann B. Guðmundsson" wrote:
> > Like to me rsyslog since the journal is an integrated part of systemd.
> 
> Because a huge change like replacing traditional logging with journald needs
> to happen as part of a process, not just because another core program adds
> similar-but-different functionality. 

Note that right now we have the journal as a requirement, and syslog
optional already. All I am asking for for F19 is not to install syslog
anymore at all, so that it becomes something which people can easily
install via yum, if they actually want it.

I am of the strong opinion that the journal can do everything we'd want
from a default logging solution. And for the ground the journal does not
cover people can install rsyslog or syslog-ng. If there's something
people are still lacking, then I am all ears.

Note that I am not saying that the journal can do everything syslog can
do, because it can't. But we left the missing bits out because we
explicitly wanted to do that, since we believe that that should be the
job for an optionally instakled syslog daemon, that runs alongside
it.

> Eventually, systemd will probably have some time-based scheduling
> functionality -- it's part of the original plan. We'll need to have the same
> discussion around cron.

We have time-based scheduling, but not calendar-based, only ba
monotonic time. Replacing cron by systemd right now makes little sense
right now, and the discussion is moot.

> Lennart, systemd developers: journalctl already has a mode which will output
> traditional-looking text log dumps. Would it be possible to offer a
> journald-compat service which writes the traditional /var/log/messages and
> /var/log/secure? Or is it better to continue shipping rsyslog for that
> purpose? This wouldn't be a "forever" solution, just a migration path, and
> eventually something which could default to off. (I can't be the first
> person to ask this, but I can't find anything with the googles....)

We have no intention to write out classic /var/log/messages files. And
also no plans in generating the UDP syslog protocol. For those things,
install classic syslog.

If people want some pixel-perfect copy of the traditional
/var/log/messages, then they should just run "journalctl" without any
args. It's much better than /var/log/messages:

a) it gets the timezone right, and translates dates to your local timezone

b) it adds PID fields to all lines, not just those where the sender
   happened to have passed LOG_PID to openlog().

c) it auto-pages if run on a tty

d) it colors errors/alerts in red, and warnings/notices in white if run on
   a tty

e) it shows you much more data, since its backend database is not
   rotated prematurely by date, but only by disk space

f) following the logs is not interrupted by rotation

g) it includes output from early boot/initrd as well, and is already
   available when you are stuck in an early boot/initrd shell

h) It's much shorter to type: "journalctl" than "less
   /var/log/messages". "journalctl -n" is shorter than "tail
   /var/log/messages". And "journalctl -f" is shorter than "tail -f
   /var/log/messages".

i) You always see the full set of logs you have access to. No need
   anymore to to look through /var/log/messages, /var/log/secure and so
   on one individually. And you get all of this nicely interleaved.

And heck, this all is just the little bits and pieces you get for free
if you just use the 1:1 equivalents to the classic commands to access
the logs. If you start to make use of filtering, of -p, of -b
(especially this one, it's soooo useful!), of -o and so on, then things
are just so much nicer for any admin to use.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.