Comment FS4P Re: Ubuntu

Story

Who's Afraid of Systemd?

Preview

Ubuntu (Score: 1)

by zenbi@pipedot.org on 2015-07-27 08:09 (#FJ12)

Probably better for Ubuntu than Upstart. They never really finished moving from SysV Init scripts to Upstart Init scripts. At least now they have one less one-off NIH project. Now if the Wayland people can convince them to give up on Mir...

My quibble with systemd is with the binary log files. There may be some workarounds to get normal text logs out of the journal, but I'd rather not have to do such things by default.

Re: Ubuntu (Score: 1)

by billshooterofbul@pipedot.org on 2015-07-28 14:24 (#FPHZ)

I really wonder what's behind the binary log complaints. If the format is open and the file gets corrupted, its still easily to figure out the content. Its not encrypted

Re: Ubuntu (Score: 2, Insightful)

by Anonymous Coward on 2015-07-29 08:07 (#FS4P)

Corruption is rarely relevant when it comes to logs. Logs in important systems are frequently archived, and as any backup they are stored in a reliable manner. The single most important thing about logs is how they are USED. If you just let the logs sit on your HDD, then there's no point in collecting them (increase your logging level to ERROR and be done with it). I, on the other hand, use logs to audit systems continuously, and if some software is introduced that makes it more difficult to analyze the logs then it is a serious problem for me.

The problem I have with journald is that it makes handling the logs more complicated, without providing any benefit compared with alternative solutions. The alleged benefits (e.g. binary logs) are already implemented in all other systems, and those implementations are more thought-through than those of the SystemD-team, as each development team can focus on polishing a single tool rather than a beowulf of programs (this is the Unix-philosophy in a nutshell). Storing logs as binary files, for example, is either done using logrotate (for archiving in compressed files) or by forwarding selected parts of the syslog stream to a database (for future analysis).

Therefore, the only way to make useful log analysis with JournalD is to configure it to forward everything to regular syslog, and add your regular analysis tools to the syslog stream. This means that in a system with both log analysis and SystemD, journald is an extra step in your pipeline which doesn't contribute with any functionality. In addition, this means that all logs (which are generated as text) must be converted into binary only to be re-converted back to text before being forwarded to analysis tools.

Now you're probably saying that tools can read the binary files straight-up in order to make things more efficient. This is true, but the problem is that there are programs which log to their own logfiles, rather than passing their logs via the syslog functionality. This means that the log analysis solution must still be capable of handling text files. This means that you must have support for both the binary format and the text format, rather than (as with other solutions) just handling text files. This (once again) increases complexity without adding any value, which is bad.

Tl;dr: Fuck Journald.

Moderation

Time Reason Points Voter
2015-07-29 18:44 Insightful +1 bryan@pipedot.org
2015-07-29 14:17 Interesting +1 hyper@pipedot.org

Junk Status

Marked as [Not Junk] by bryan@pipedot.org on 2015-08-22 00:18