"systemctl status foo" was too slow

For quite a while now, running any sort of systemctl status foo command seemed to take forever on any and all of my systems. That exact command would sometimes take as long as 30 seconds to return complete, despite foo not even being an available service. I noticed it more on my aging laptop than on my other systems, but I just attributed the slowness to my hard drive maybe preparing to fail.

Anyway, I finally got frustrated enough to actually put some effort into seeing what the problem might really be and how I could avoid the terrible delay for something so simple. It dawned on me that the actual status of the service was coming back pretty fast, but getting any recent output from the service is what took forever.

This led me to look into systemd's journald. I checked the /var/log/journal/xxxxx... directory on my laptop. It was massive--4.5GB of logs of whatever. I know better than to just go deleting files out from under a running process, so I looked into ways to simply truncate the logs. This led me to a few pages that all suggested that I modify /etc/systemd/journald.conf to optimize things a bit.

The configuration options that I kept seeing were SystemMaxUse and RuntimeMaxUse. When I set these both to 10M and restarted journald (systemctl restart systemd-journald), my /var/log/journal/xxxxx... directory was nice and tidy again. And systemctl status foo-like commands returned muuuch faster.

I suppose I'll be adding this stuff to my configuration script!