I think my biggest gripe with journalctl is (and this may just be because I'm novice at using it) that discovering what sort of logs are on the system feels a lot more complex.
With regular logs, I can go to /var/log, ls the dir, and get a nice list of what's being logged. There will be, for example, an `apache.log` file that has all the logs relevant to apache.
It's just journalctl -u apache -f, assuming your distribution calls the unit file "apache", and the last few messages of the logfile appear with systemctl status apache
And you don't need to worry about "is this service rotating logs appropriately?"
The important thing for me at least isn't he `-u apache` but rather knowing that `apache` exists as one of the installed services on this box.
In the old ways, that was apparent because of the presence of the log file.
Granted, this isn't the problem it used to be for us, however, it would come up because we'd have our services named things like `foo-ws` and knowing that `foo-ws` existed on a given box might be tricky were it not for the log files.
correct me if i’m wrong, but i believe the point that is trying to be made is;
a system user/admin has an intuition about files. saying that ‘journalctl -f -u’ (fu, indeed :) and whatever else is inherently undiscoverable, and is a.. basically orthogonal mechanism for handling what should be a simple task. i.e., viewing some logs. it’s far easier to compose and extend from files (what if i only care about the mtime of the log, for instance), than this.
look, i think systemd isn’t.. terrible. i also think it’s suffered a bit of complexity fetishisation, and it seems as though that this resulting complexity may have become invisible to you.
run0 doesn’t seem like a bad idea. but i am wincing a bit at the thought of unrestricted javascript determining access control.
I think you have me confused with someone who cares about the difference between binary and text logs. I have no pony in this race; my comment was just made to help.
With `ls -l` I can see file modification dates. How do I do it with journalctl? And why do I need to that that in the first place?
Journald would be perfect if I didn't have to know a thing about it. Work in background, move stuff from stdin/stdout to /var/log/journald/service.log, move old stuff in /var/log/journald/archive/service/2024-04/15.log.gz. I'd be happy. Why do I need this cryptic CLI I don't understand. It brings nothing but pain.
I mean "systemctl status" shows all services and their hierarchy, there's also "systemctl list-unit-files" if you want to see things that aren't part of the current target (runlevel).
It's much easier in the systemd world to see the state of the system, the state of the service, and the logs of a service because it enforces this consistency.
honestly that's such a niche problem to have that i dont think it's worth throwing the baby out with the bathwater. anyways you shouldn't be discovering installed services by logfile presence, it should be something like querying your package manager.
I wouldn't say it's a niche problem. I also miss being able to go to /var/log and see instantly what's going on.
There should be a command like "journalctl --top" that would list all logging services with amount of logs, oldest and latest log times, and last few lines of each, to improve that experience. Maybe there is already a way to do something similar?
With regular logs, I can go to /var/log, ls the dir, and get a nice list of what's being logged. There will be, for example, an `apache.log` file that has all the logs relevant to apache.