On Mon, Aug 6, 2012 at 5:52 PM, Daniel P. Berrange <berra...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
