[systemd-devel] ExecRestart

[Daniel P. Berrange]

On Wed, Dec 19, 2012 at 11:46:13PM +0100, Lennart Poettering wrote:
> On Wed, 28.11.12 22:41, Brandon Black (blblack at gmail.com) 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 :|