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 ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
