> Lennart pointed out the fact you can see readable messages via strace to be a benefit of json.
from the guy who brought you binary logfiles!
from the guy who brought you binary logfiles!
Per https://systemd.io/JOURNAL_FILE_FORMAT/, the benefits of the binary format are:
The systemd journal stores log data in a binary format with several features:
Fully indexed by all fields
Can store binary data, up to 2^64-1 in size
Seekable
Primarily append-based, hence robust to corruption
Support for in-line compression
Support for in-line Forward Secure Sealing
As a user system-administrator, I see the cryptographic checksum as a benefit of being able to show tampering evidence of on-system log files.
It's so robust, it doesn't even let you modify the journal if you want to (e.g. https://github.com/systemd/systemd/issues/20673).
> Support for in-line compression
Mind that journald only supports compressing single lines, but not the whole journal (https://github.com/systemd/systemd/issues/31358), which is pretty limiting.
In what situations is it a harder problem than this?
It's a tradeoff, if you do full compression clearly it won't be fast.
You're free to compress it again before archiving it.
Text logs are append-based and seekable as well.
> Support for in-line Forward Secure Sealing
I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides.
Also, I am tired of waiting minutes for a journalctl query to load.
I hope this was a personal system. Changing logs in this manner would have almost certainly led to your dismissal anywhere I ever worked. This anecdote just re-enforces the need for Forward Secure Sealing.