How avoid unwanted systemd-journald?

[Joonas Sarajärvi]

2013/11/17 Frantisek Hanzlik <franta at hanzlici.cz>:
> Steven Stern wrote:
>> On 11/15/2013 04:46 AM, Frantisek Hanzlik wrote:
>>> For one thing I'm in the conviction that binary logs are hazardous
>>> bullshit,
>>
>> In what way might the logs be hazardous?
>
> It was mean mainly from administrator view. When things go bad,
> machine HW/SW fail or any other disasters occurs, logs are very
> valuable. And I'm confident that binary logs are too weak in this
> situation. Text logs are useful even if log file is damaged or ends
> with fragments and can be easy readable with lot of tools. Binary
> logs, by contrast, may be useless when log file is damaged or I
> haven't this one unique utility for reading them. And my experiences
> with systems where binary logs are implemented says clearly that
> binary logs is bad idea.
> Second, it is question when tight integration of systemd and logging
> services has any benefits - there is number of situation (logging
> over network, for example) which speaks for separate logging service.

The journald log format is documented at least to some extent [1], and
there exists free software for reading the log. To me, it sounds like
way more accessible than if it was a binary data format of a typical
proprietary tool. For example, booting any Fedora live image should
suffice if you need to read the journal of a system that uses journald
and happens to become unbootable.

Typically journalctl will generate you a representation of the data in
syslog log file format. This loses some infromation that the journal
stores, because there is no way to represent it all while keeping the
output syslog-like and easily human-readable. This output can be
easily fed to traditional unix tools like grep, if that is your
preferred way of extracting information from logs.

Finally, since you can also run a normal syslog daemon which maintains
a text-format logs for you, I do not really see why having some log
data in journald format under /run/log/journal/ should be considered
hazardous. You can pretty much just ignore it if you feel like using
other kinds of tools for storing and managing logs.

> And possibilities with e.g. rsyslogd are better than with journald
> - why Fedora must again replace verified, reliable, Unix standard
> things with some crappy solutions? For nightmares of its users?
At least for my needs, the journal has been way more convenient to use
than rsyslog. It is much nicer to read logs when journalctl e.g.
combines the older rotated logs with the latest ones. Also, it easily
allows me to easily specify that I want just the logs of this month or
of just this one boot, or of just some specific service.

If I was writing tools that'd automatically handle the logs, I think I
would also benefit from the additional data that journal stores that
is usually not available in a syslog formatted log. Having to use e.g.
the journal API would of course be some burden, but I can imagine it
being nicer than having to e.g. parse all the different date formats
that a text-formatted log could have. Or having to handle all of the
other things that may or may not be in the syslog lines, in various
formats.

Of course there are still bugs and the other issues in the new tools,
but they certainly aren't there in order to cause nightmares. I am
hopeful that the issues can be and are fixed. For my (relatively
simple) setups, there aren't any major showshoppers, though.

[1] http://www.freedesktop.org/wiki/Software/systemd/journal-files/

-Joonas