== My irritation with '_systemctl status_'

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
SystemdSensibleOutput]].

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

=== Sidebar: How _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 _--full_ aka _-l_ in
effect. Appropriate command line switches would change this behavior
around in various ways (always show log lines, never show log lines,
etc).

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