And you don't need to worry about "is this service rotating logs appropriately?"
And you don't need to worry about "is this service rotating logs appropriately?"
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.
journalctl -f -u <TAB>
Shows you all installed units if you have working shell completion, or 'a<TAB>' gets you all units starting with 'a', etc.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.
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.
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.
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?