6 ms·
Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to e
by surajrmal 2y ago
Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to ever need high volume or large messages, then it's not really likely to be a problem in practice. He also pointed out that they waste far more cycles today on context switches (he suggested something on the order of 6 per IPC message).
Even if they eventually come to the conclusion they need something more performant in the future, it's probably still a net win to make the switch today. It's also possible it turns out fine for their use case.
I personally would think they would want to benefit from an IPC system that includes provisions for sending file descriptors.
- markasoftware 2y ago> 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!
- solarengineer 2y agoOne can view the binary log files using journalctl. Per https://systemd.io/JOURNAL_FILE_FORMAT/ 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.
- Dunedan 2y ago> Primarily append-based, hence robust to corruption 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 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 https://github.com/systemd/systemd/issues/31358), which is pretty limiting.
- guappa 2y agoIn sicily we'd call this "vuliri a vutti china e a mugghieri 'mbriaca". 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.
- viraptor 2y agoModifying the existing journal really sounds like the wrong solution. Just "journalctl --rotate" the file and throw out the one with accidental PII. Journal files are not great for long-term storage or search. You can export the old file and filter out manually if you really want to preserve that one https://www.freedesktop.org/wiki/Software/systemd/export/ https://www.freedesktop.org/wiki/Software/systemd/export/ In what situations is it a harder problem than this?
- orbisvicis 2y ago> Primarily append-based > Seekable 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.
- tssva 2y ago> 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. 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.
- orbisvicis 2y agoNo, I just left it there.
- deleted 2y ago[deleted]
- 01HNNWZ0MV43FF 2y agoCan't win huh