> 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 t

> 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).