F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Wed, 17.07.13 15:08, Lennart Poettering (mzerqung at 0pointer.de) wrote:
> > How about this idea.  Before "No Defualt Syslog", systemd needs to
> > completely replicate all functionality provided by syslog, including
> > /var/log/messages, by default.  Syslog emulation would be an option, and if
> > people don't want it, they can still turn that option off.  But by default,
> > everyone can still grep /var/log/messages.
> 
> Not. Gonna. Happen. 
> 
> The journal is not an implementation of syslog, we already have that in
> rsyslog. Also, the feature is about ending the duplicate storage of the
> log messages, so your suggestion is completely against what the feature
> is about.

And to add to this /var/log/messages the way it stands right now is
*very* badly designed:

  The timestamps do not contain a year
  The timestamps do not contain a timezone
  The timestamps are accurate to the second only
  PID information is optional, not implied
  PID information is fakeable, because user supplied
  The file "tag" part is completely optional, free-form, and fakeable by unpriveed clients
  The files do not carry any information about the log priority
  The files do not carry any information about who is logging (service, process name, argv, binary path..)
  The files do not carry any information about the credentials of who is logging (uid, gid, selinux context, audit, ...)

And so on and so on.

It's so bad, that rsyslog upstream even suggests not to use these files
anymore, but write them in a more modern formatting that leaves a bit
more information in (such as iso timestamps). But you know what? If you
do that than all your compatibility is gone too.

The interesting things is that "journalctl" is *better* at generating
the same text stream that is normally contained in /var/log/messages
than /var/log/messages itself is. "journalctl" can stuff more
information into it then /var/log/messages. And how does that happen?
Because we have more data around. We can agument the ouput with colors
(indicating priorities), we can add additional informational separator
lines (indicating reboots), we can add add in fields that aren't there
(such as the tag from the comm field, or the PID). We can timezone
correct the timestamps (because we have UTC times). And we can filter by
any of the fields, securely.

So, yeah, /var/log/messages sucks, and journalctl is better at
generating a compatible output that that file ever was in itself.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.