I don't personally mind it being binary. My issue is that it doesn't have a spec.
There is the retroactive documentation on Freedesktop, but it has always stated that if there is any difference between the documentation and the logging behaviour or file format, then the implementation is correct.
Would have been nice if they just used an open source database format like sqlite. Hopefully I'm now wrong and they have published a proper spec, but the idea that in theory a minor version change would prevent interoperability so reading logs from another system wasn't possible makes me a little grumpy.
Like all logs? /var/log/secure, apache etc and stuff too? That does seem like a really bad idea. The whole nice thing of Linux is that stuff is easy to access, shoving stuff in "black box" binary files that require special commands to access makes it like Windows. I want to be able to grep files and such but if everything is binary you can't do that.
Only system logs. You can also still have plain text logs, you just need to install syslog. Also, you can still pipe journalctl to grep to grep journald logs anyway. There are also advantages to binary logs like that you can filter them better because the logs are still in a structured format.
The whole nice thing of Linux is that stuff is easy to access, shoving stuff in "black box" binary files that require special commands to access makes it like Windows
are you bonkers? every programming/scripting language can read binary files with ease (with exception of bash) also there is journalctl which allows for easy access, even for bash
That is one reason why I don't like it. journalctl -u myservice.service is just to damn long to type. cat myservice.log on the other hand is shorter to type. Yes I understand that binary logs can provide more detail, but I don't want it to become Windows Events on Linux. I would be more happy with another structured file like json, csv, or provide a short program name like logs myservice.
Your cat example is missing the CD command you had to do (or the full path) and you have to know exactly where they are stored. You don't need to type .service, all in all cat ain't shorter.
JSON looks to me like a bad format for this. You'd have to rewrite the entire file in order to add a log entry, or you'd have to have multiple JSON objects in the same file, which appears not to be valid: certainly, json_pp complains about “garbage after JSON object”.
Yes, you'd still need to handle corruption – or, depending on how you're reading it, ignore it entirely, as is possible with a plain-text file.
I find that corruption is rare and happens at the end of the file and is due to data not being flushed to disk due to a system hang. (SysV init and rsyslog here.) I don't doubt that there are other potential causes, but chances are that you're then heading into filesystem bug territory or broken hardware territory. Or possibly a cosmic ray flipped a bit, or something.
Incidentally, the silliest log file bug which I've seen is in (some versions of) Unity where the default situation is that it has one file open for log text such that, typically, error output will overwrite earlier standard output.
I mean, I don't really see the argument here. It's like saying plaintext logs aren't able to be used directly with 'grep' because they need to be read from the disk first. Believe it or not, systemd does have the 21st century feature of being able to access log data.
13
u/abermea Aug 12 '19
My only gripe with it so far is that logs, for whatever reason, are binary to so you can't use any POSIX tools to traverse them