The logging is amazing. Transparent compression, easy search, output in JSON if you want to parse logs, timestamps with microseconds if you need them.
No, writing stuff to a file was not fine. It's only fine if all you do is to 'tail' and 'grep' it, but any time you want to do something more advanced, it's a bloody mess.
Why parse a text date, when it started its life as an unix timestamp? Why write a bunch of regular expressions trying to get basic data such as an HTTP response code, when it could be a field in the log that you could just search for? Why deal with parsing while the log may rotate or truncate under you, when the log system could be making your life easier?
I wrote a whole bunch of log parsing stuff in my day, and so I have no nostalgia whatsoever regarding this "just write stuff to a file" approach.
Amazing for you maybe. If you have a slower spinning HDD journalctl -eu <service> takes 10-30 seconds (not an exaggeration). Meanwhile cat or tail -f of a log file is almost instant somehow.
> Why write a bunch of regular expressions trying to get basic data such as an HTTP response code, when it could be a field in the log
I mean, this is a problem which doesn't require systemd to solve, you just need a better log format. Someone could have standardised a line based logging format with fields and then someone else could have written libraries to write it and libraries to parse it.
> Why deal with parsing while the log may rotate or truncate under you
That's a log daemon problem that I haven't found to exist with any log daemon I have used.
> If you have a slower spinning HDD journalctl -eu <service> takes 10-30 seconds (not an exaggeration).
That's because you're asking for a log of a service since logging began, which may well have been months worth of logging. You're saying "give me everything that happened ever to this service in a pager, then scroll down to the bottom".
If you want tail -f, use a -f: 'journalctl -f -u <service>'. That's going to be a lot faster. You can also use '-b' to make it return a log of what happened since boot (worth looking into the manual for the details of that one), or specify a start date with -S, like '-S yesterday'.
> Someone could have standardised a line based logging format
And what were they waiting for? In the end, systemd did it, but it's a pretty recent invention. There was plenty time to get there first.
> That's a log daemon problem that I haven't found to exist with any log daemon I have used.
Because log daemons classically don't care about this at all -- it's a problem for whatever reads the files that the log daemon generates afterwards.
> That's because you're asking for a log of a service since logging began, which may well have been months worth of logging. You're saying "give me everything that happened ever to this service in a pager, then scroll down to the bottom".
journalctl -fu is just as slow. I don't keep months of logs and the amount of logs I do keep easily should fit within a minimal amount of space. Somehow systemd manages to screw this up completely and I really don't think this has anything to do with user error.
> And what were they waiting for? In the end, systemd did it, but it's a pretty recent invention. There was plenty time to get there first.
I don't know what people were waiting for. But I think what systemd did could have been done in a more transparent and decoupled fashion that didn't involve binary logs. Just because they did something right doesn't mean that the way they went about achieving it isn't inherently flawed. I get that logs suck but fixing that shouldn't require me to change my entire system management stack.
> Because log daemons classically don't care about this at all -- it's a problem for whatever reads the files that the log daemon generates afterwards.
The log daemon I use (svlogd) first closes the current file, renames it and then opens a new empty current file. If it finds that there's now too many old logfiles it deletes the oldest one. I don't see how this could possibly break any tool which is reading the file except for cutting the stream short when tailing during a rotation. Moreover I don't think that's a problem since if you need to do some kind of processing of the logs then you should just put that in front of or after the instance of svlogd in the pipeline (svlogd can be asked to forward logs to stderr which then means you can chain it with something else).
journalctl -fu takes over a second on my NAS with the logs on an SSD even.
I fucking hate systemd's logging so much due to this crap, don't make me read docs for every little thing, I just want to cat a damn log file, pipe it through grep and call it a day.
No, writing stuff to a file was not fine. It's only fine if all you do is to 'tail' and 'grep' it, but any time you want to do something more advanced, it's a bloody mess.
Why parse a text date, when it started its life as an unix timestamp? Why write a bunch of regular expressions trying to get basic data such as an HTTP response code, when it could be a field in the log that you could just search for? Why deal with parsing while the log may rotate or truncate under you, when the log system could be making your life easier?
I wrote a whole bunch of log parsing stuff in my day, and so I have no nostalgia whatsoever regarding this "just write stuff to a file" approach.