How avoid unwanted systemd-journald?

[Frantisek Hanzlik]

Joonas Sarajärvi wrote:
> 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

I'm convinced it is as similar things on eg. ms windows (binary logs,
registry,...) - when is all working fine, then it look fine too.
But when machine somehow fail, then this binary mud is serious problem.
And I do not want to wait to time, when for some similar failed crap
I have to reinstall Linux box. Until now I never needed it, no matter
how significant Linux box crashes were...
Franta Hanzlik