[systemd-devel] Re-exec()ing services for 'systemctl restart' ?

[Kay Sievers]

On Mon, Aug 6, 2012 at 5:52 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> For libvirt, we (will soon) have a daemon (virtlockd) which maintains
> exclusive fcntl() based locks on disk images/devices, on behalf of both
> libvirtd and any running QEMU or LXC instances. This is a safety critical
> daemon (hence separate from libvirtd), to the extent that if the daemon
> stops / crashes, the entire host should be immediately fenced using a
> kernel watchdog and/or hardware power control device.
>
> We still want to be able to restart this daemon during RPM upgrades to
> newer versions, but we can't use a normal stop+start sequence, because
> that will loose locks for any active VMs. Thus the daemon has the ability
> to re-exec() itself triggered by SIGUSR1, preserving its critical state.
> I've read the manpages for .service, .exec, etc but I've not seen any
> reference to changing config such that
>
>   # systemctl restart virtdlockd.service
>
> will simply send SIGUSR1 to the process, instead of stopping it and then
> starting it again. Obviously I could make the RPM %post send SIGUSR1
> directly and ignore systemctl, but that doesn't help admins who just
> expect to use systemctl. So I want to know if there is a recommended
> way to handle this kind of use case ?

$ systemctl reload ... ?

or with the signal speficied:

$ systemctl kill ...

Kay