Understanding what 'systemctl restart' means and when I want to use it

February 18, 2021

Over on Twitter, I exposed a systemctl misunderstanding of mine in public:

I wish systemd had a 'systemctl restart-or-start <unit>' option, so you didn't have to care if you were doing a new install of something or an upgrade.

As some people pointed out to me, I had misunderstood 'systemctl restart'; this is exactly what it does. For some reason I had it in my mind that 'systemctl restart' only restarted already running services. Interpreted another way, 'systemctl restart' insures that the latest (ie current) version of a service is running. If it's not running at all it's started (implicitly using the latest version) and if it is running it's stopped and then started again, insuring that it's running the latest version.

One corollary of this is that I almost always want to use 'systemctl restart' in scripts and automation instead of 'systemctl start', because then the same automation works for both initial installs and upgrades. Often I want to use it interactively as well, since 'restart' is almost entirely a superset of 'systemctl start'.

As I already knew, 'systemctl start' starts a service if it's not running but doesn't restart it if it is. This is what I want if I want to insure a service is running but not restart the service if it already is, for example if stopping and starting a service again is user-visible or disruptive. 'Systemctl start dovecot' is fine if I think Dovecot isn't running and is harmless if I'm wrong and it already has been started. By contrast, 'systemctl restart dovecot' will terminate all current IMAP sessions if Dovecot is already running (although clients usually transparently make new ones).

What I thought 'systemctl restart' did is actually 'systemctl try-restart', which only stops and starts units that are actually running. Using 'try-restart' is appropriate in things like Let's Encrypt automation, where we don't want renewing a certificate to start up daemons that we've deliberately stopped (or that we never enabled in the first place). There's also 'try-reload-or-restart' which does a 'systemctl reload' on running units that support it.

(Fortunately I don't think any of our current scripts do a 'restart' where we really want a 'try-restart'. All of our daemons that use Let's Encrypt certificates support 'reload', so that's all we're using on them.)

Written on 18 February 2021.
« TLS certificates specifying hosts via their CommonName field is more or less gone
ZFS pool partial (selective) feature upgrades are coming in OpenZFS »

Page tools: View Source.
Search:
Login: Password:

Last modified: Thu Feb 18 23:38:07 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.