On Wed, Dec 19, 2012 at 11:46:13PM +0100, Lennart Poettering wrote: > On Wed, 28.11.12 22:41, Brandon Black ([email protected]) wrote: > > > The daemon's "fast restart" code does all of the expensive startup > > operations in the new daemon first (e.g. parsing large data input), then > > signals the existing daemon to shut itself down, waits for it to release > > its critical resources (e.g. sockets, pidfile), and finally takes over > > those resources and finishes starting itself. Basically it's using the > > overlap to avoid long service downtimes during that initial parsing phase > > (and if that parsing fails, it leaves the old daemon running to boot).
[snip] > Or in other words: > > I am pretty sure that we should not alter the current restart logic, and > should not introduce ExecRestart=. However, we really should think about > either introducing ExecReexec= or somehow making ExecReload= useful for > reexec-style reloading, too. But I haven't made my mind up on this, how > this could look like. FWIW, as previously mentioned, I'd love to see an explicitly supported way to trigger a re-exec of a daemon. Currently I'm just relying on the ability to send a custom signal to libvirt's virtlockd daemon. The problem is that sysadmins would need to learn a different signal number for each project's daemon. So I think there's value to admins in having a standard way to trigger this via sysadmin. Personally I think this should also be separate from ExecReload which is merely used to refresh configuration files. 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
