My irritation with 'systemctl status'

August 10, 2015

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

Written on 10 August 2015.
« One potential problem with cloud computing for us is the payment model
What free is really telling you, and some bits from /proc/meminfo »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 10 01:41:16 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.