Well, to be fair you can't exactly ask typical syslog demon "give me log files of an app" but the way journalctl implemented it is just fucking terrible.
It takes 4 whole seconds [1] for systemctl/journald to tell me it has no logs for the daemon on my NAS and it opens 985 files while it is doing it
If it just used sqlite as a backend it might've been useful for analysis (on top of way faster...) but Lennart wanted to have a go at implementing binary DB format badly so we're stuck with it.
If it at least kept a pointer to last file the app's logs were written to the lack of proper indexing also wouldn't be a problem.
But nope, it's just entirely worse than text format. And I do mean that in entirety, acking thru text files is faster than systemctl trying to find log files for the app...
My favorite experience with journalctl from many years ago was when an application kept spamming the logs till there was no space left. Once that point was reached, the binary logs got corrupted so couldn't be opened to investigate the cause. Don't remember how many turns it took me.
It takes 4 whole seconds [1] for systemctl/journald to tell me it has no logs for the daemon on my NAS and it opens 985 files while it is doing it
If it just used sqlite as a backend it might've been useful for analysis (on top of way faster...) but Lennart wanted to have a go at implementing binary DB format badly so we're stuck with it.
If it at least kept a pointer to last file the app's logs were written to the lack of proper indexing also wouldn't be a problem.
But nope, it's just entirely worse than text format. And I do mean that in entirety, acking thru text files is faster than systemctl trying to find log files for the app...
* [1] https://github.com/systemd/systemd/issues/2460