How to configure systemd to kill and restart a daemon on reload?

Solution 1:

The answer is, "you don't"! But we have good news.

systemd's philosophy is that reload is optional and should be left undefined if there is no true reload functionality. I'd define "true reload functionality" as a reload that does not kill and restart the service, or make the service change its PID. In other words, systemd only wants to reflect what features exists.

Instead, you should use systemctl reload-or-restart which will do a reload if it exists, and a restart if it does not.

From the man page...

   reload-or-restart PATTERN...
       Reload one or more units if they support it. If not, restart them
       instead. If the units are not running yet, they will be started.

   reload-or-try-restart PATTERN...
       Reload one or more units if they support it. If not, restart them
       instead. This does nothing if the units are not running. Note that,
       for compatibility with SysV init scripts, force-reload is
       equivalent to this command.

Therefore: (1) leave ExecReload blank, (2) use systemctl reload-or-restart MYSERVICE and, (3) you should be all set.

If you do try to use ExecReload to define a way to kill and restart the service, it will have a new PID and systemd would be confused.

Solution 2:

systemd's philosophy is that reload is optional and the user of systemd should know, for every service, whether it should call reload or fake it by calling restart.

Therefore, the answer to your question is, "It doesn't work, and it shouldn't. Please solve this at the next higher layer."

In other words, systemd wants you to only implement "reload" if the underlying service supports a true reload functionality... i.e. a reload that does not kill and restart the service, or make the service change its PID. In other words, systemd only wants to reflect what features exists.

You may be asking yourself: But wouldn't it be easier if I could implement a "fake" reload by allowing ExecReload to kill and restart the service? Then I could use systemctl reload FOO for all my services and I wouldn't have to remember which ones support it and which ones didn't?

Yes, that would be easier, but that wouldn't be systemd's way. Systemd wants the caller to be the thing that knows if reload exists for the service. Systemd wants to be a common interface to the features that exist, it doesn't want to be responsible for filling in the gaps.

For example, puppet assumes that a systemd-driven service has no reload and defaults to killing and restarting the process. If the Service[] type added a way to specify that reload exists, and that it should be used on notification, it will need to learn which services have or do not have a native reload. Chef and all other systems would also have to learn the same thing because systemd wants it solved at that layer. (MiniRant: for starting a process systemd seems to be the all-knowing, all-mounting, all-namespace-customizing i-do-everything-at-my-layer system. Therefore I can't tell you why it doesn't extend this philosophy to reloading. Maybe one of the authors can chime in here.)