HACKER Q&A
📣 flippinburgers

Why does systemd insist on using binary logs?


I am curious to know the reasons. Moving away from text makes very little sense to me.

- Binary gives minor compression advantages from what I understand.

- Having to learn yet-another-tool seems a real pain.

- A walled garden is good from the point of view of the creators of systemd?

- Arrogance?


  👤 jchw Accepted Answer ✓
Compressed logs are already binary anyway, so at that point, you'd definitely not be eating much cost to just go the rest of the way.

As for why binary, it's more like, why not text? And my main answer is that everyone thinks that parsing text formats is easy, because it is, so when you have a dumb text format somewhere crucial, you wind up with a gazillion crappy parsers that are all flawed in different ways. Binary formats almost universally tighter in their specification, require less complex algorithms to parse, and so on. Like, seeking around a binary file with indexes is WAY faster, more efficient, and simpler than seeking around a text file with delimiters. Even just length-prefixing can help a TON, especially if you have certain extremely large log lines. (Believe me, I do wind up with that, especially in production environments.)

The `journalctl` tool is handy. It's easy to tail the entire system's logs with `journalctl -f` which I use all the time when debugging usermode problems and I have no idea where the logs are. Adding `-u [unit]` to target a specific unit is not much harder, or -x for the pager, or -e to go to the end of the pager.

If I want to run a process and have it log to systemd, that's also very easy. Just run it with the systemd-cat wrapper. This connects stdout and stderr to the journal directly.

Binary doesn't have to hurt more than text; it's very fast and efficient to turn it back into whatever text format you might want. Making it not hurt is the job of the tooling. I feel like systemd has improved a lot here and now for pretty much any use case I don't really see the downside of the way it handles journaling.

As it always is... YMMV. I'm curious to hear what kinds of practical problems people have, though I assume most of it is "I had something processing logs directly, and now it doesn't work." But even if that may be annoying, I think it's usually not too hard to solve either.


👤 bjourne
Binary logs probably makes it easier to enforce a specific field format. With other logging daemons some programs would log timestamps iso 8601 others would use unix time or the locale's timestamp format. Same with log message types (ERROR, WARNING, INFO, NOTICE, ...) and multi-line log messages.

systemd is now over ten year old and no one has had any major problems with the binary log format. So I think Lennart proved the doubters wrong.


👤 mrktf
Personally never touched, but one argument was for forward secure sealing (cryptographic log data signing and periodic scanning for data tampering)

https://lwn.net/Articles/512895/


👤 nikau
because being able to do "cd /var/log && zgrep errorstring *" was too convenient