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

[Kay Sievers]

On Mon, Aug 6, 2012 at 6:14 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Mon, Aug 06, 2012 at 06:04:11PM +0200, Kay Sievers wrote:
>> 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 ... ?
>
> I thought about reload, but using that to re-exec the daemon seemed
> a little evil to me, since it was really for just reloading config
> files.

It's probably a not too interesting detail for systemd, the PID will
stay the same, so only reloading the config or also doing an exec() is
all not really visible to systemd. You can think of reloading the
executable image not only its config. :)

You know about the sd_notify(3) API, right? It might be nice to update
systemd with what the service is doing here.

>> or with the signal speficied:
>>
>> $ systemctl kill ...
>
> True, I guess I could use that.
>
> I'm infering from your response that there's no way to customize what
> 'restart' does, as you can do with stop/start/reload/etc.

Right, restart is more a stop+start, where the PID usually changes and
systemd needs to re-init the supervision/tracking.

Kay