My irritation with '
Let me say up front that '
systemctl status' is on the whole a
really great command. The basic information it reports about a
service is very useful, and it's extra-useful that you can give it
a random PID and it will tell you what it belongs to (and what all
of the other processes are). There is just one little drawback to
it, namely that it also helpfully defaults to showing you recent
log messages for the service.
In theory this is a great idea, because in theory things like looking up log messages in the systemd journal takes irrelevant amounts of time. In the real world that I inhabit, systemctl looking up this information causes lurching multi-second pauses (with disk IO storms). Then to add insult to injury, systemctl defaults to showing these log messages in a relatively useless way.
If you remember, you can force systemctl to not show you any log
lines with '
systemctl status -n 0 ...'. Then if the service is
in an error state, where you actually do care about the log lines,
you get to re-run the command again so you can see them. Remember
to use '
--full' so you can see them in a useful form.
In practice, the odds that I will remember '
-n 0' approach zero
and so the odds that '
systemctl status' will continue to irritate
me on the moderately infrequent times that I run it approach
systemctl status should behave
By default, '
systemctl status' should not try to report any log
lines if the service's status is normal. If the service's status
is abnormal, for example if it errored out on startup, the last N
log lines should be shown in full, ie with
effect. Appropriate command line switches would change this behavior
around in various ways (always show log lines, never show log lines,
I don't expect the systemd people to ever change things here, so I'm not going to bother filing this as an RFE or a bug.
(And yes, I expect that this runs rather faster on machines that use SSDs instead of spinning rust. That's one reason I suspect that an RFE would not be well received.)