Hacker News Reader

Comment by gupnop | Hacker News Reader

There are solid technical reasons for systemd's binary logging.

The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones.

Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.

View on HN

For me, the nice things about the systemd journal binary log format are:

- It's immediately compressed (without having to wait for a log rotation);

- It automatically rotates when a size limit is reached (no risk of filling the disk with logs);

- IIRC, it's deduplicated (repeated messages use less disk space).

All of these together means logs can be kept for much longer by default.

Overall agree. The only problem is if you have file corruption it could be a problem to parse. But I usually don't change the default.

> indexed for quicker searching and filtering

I think I am not the only one who is missing negative filters - check the log excluding audit messages.

Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.

If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?

Just nitpicking, but AFAIK it's not journald which is used to read the logs, it's journalctl itself which directly reads the binary logs from the filesystem (and the normal filesystem ACL permissions are used to allow or deny reading the logs).

Rsyslog can be configured with a database backend, if you want to index the log fields.

Reply on news.ycombinator.com