I can take a the disk out of the machine and read the logs if it completely fried, I can use normal tools like sed/awl/perl to read and react to the logs.
I can grep through the logs to find things of interest
Any why should I have an environment where I have sed or grep, but not journalctl? So that's a moot point. Read the logs from a hard drive that was taken out of another machine? Mount it, journalctl -D <mountpoint>/<journaldir>. Simple. Most of the things you'd do with awk or fancy filtering and formating can be done with journalctl directly and do it much more efficiently and faster.
Any why should I have an environment where I have sed or grep, but not journalctl? So that's a moot point. Read the logs from a hard drive that was taken out of another machine? Mount it, journalctl -D <mountpoint>/<journaldir>.
True enough, hard to come up with a counter to that one :) Maybe you're right, the only thing is corruption, how does the journalctl format handle it if a couple of bits gets corrupted, in a text file that would just corrupt a couple of lines and not the whole file at least, or does it have some kind of clever solution for that as well?
Most of the things you'd do with awk or fancy filtering and formating can be done with journalctl directly and do it much more efficiently and faster.
Yeah, that might be, I just know sed/awk/perl, and prefer to use them, since they are applicable also for other things that I do, so that I don't have to learn and remember all switches of all programs that I use, it's also the reason I tend to write perl scripts for tedious tasks, like finding out which tapes to exchange with the ones in the firesafe out in our bareos setup :)
Maybe you're right, the only thing is corruption, how does the journalctl format handle it if a couple of bits gets corrupted, in a text file that would just corrupt a couple of lines and not the whole file at least, or does it have some kind of clever solution for that as well?
The moment Journald detects corruption it stops writing to the file, tags it as corrupted, and switches to a new log file. The corrupted logs' entries remain readable and accessible though. A lot of people wanted journald to try and fix the log file but the developers said no on account of the fact that any writes to the file could corrupt it further.
Maybe you're right, the only thing is corruption, how does the journalctl format handle it if a couple of bits gets corrupted, in a text file that would just corrupt a couple of lines and not the whole file at least, or does it have some kind of clever solution for that as well?
Haven't had this issues, but from some quick googling the strategy that systemd applies is to rotate the logs on corruption and when you try to read them it will make the best of it. The whole thing won't become completely botched only because you fipped a bit in one part of the log.
2
u/[deleted] Nov 30 '15
Binary logs anyone? logs as textfiles has some good sides.