[libvirt] [PATCH] Configuring systemd to restart libvirt on abort

Mooli Tayer mtayer at redhat.com
Tue Jul 30 14:04:10 UTC 2013



----- Original Message -----
> On Tue, Jul 30, 2013 at 04:27:37PM +0300, Dan Kenigsberg wrote:
> > On Tue, Jul 30, 2013 at 05:43:16AM -0400, Mooli Tayer wrote:
> > > 
> > > ----- Original Message -----
> > > > On Mon, Jul 29, 2013 at 05:36:21PM +0300, Mooli Tayer wrote:
> > > > > From: Mooli Tayer <mtayer at redhat.com>
> > > > > 
> > > > > This will create a respawn behaviour in case libvirt
> > > > > process exits due to an uncaught signal not specified
> > > > > as a clean exit status.
> > > > > see
> > > > > http://www.freedesktop.org/software/systemd/man/systemd.service.html
> > > > > ---
> > > > >  daemon/libvirtd.service.in | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in
> > > > > index aa5913b..b3c0849 100644
> > > > > --- a/daemon/libvirtd.service.in
> > > > > +++ b/daemon/libvirtd.service.in
> > > > > @@ -15,6 +15,7 @@ EnvironmentFile=-/etc/sysconfig/libvirtd
> > > > >  ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS
> > > > >  ExecReload=/bin/kill -HUP $MAINPID
> > > > >  KillMode=process
> > > > > +Restart=on-abort
> > > > >  # Override the maximum number of opened files
> > > > >  #LimitNOFILE=2048
> > > > 
> > > > I'm wondering whether 'on-abort' is the best choice or if
> > > > 'on-failure' or 'always' are better. The systemd.service
> > > > man page says
> > > > 
> > > > [quote]
> > > >            Takes one of no, on-success, on-failure,
> > > >            on-abort, or always. If set to no (the
> > > >            default) the service will not be restarted. If
> > > >            set to on-success it will be restarted only
> > > >            when the service process exits cleanly. In
> > > >            this context, a clean exit means an exit code
> > > >            of 0, or one of the signals SIGHUP, SIGINT,
> > > >            SIGTERM, or SIGPIPE, and additionally, exit
> > > >            statuses and signals specified in
> > > >            SuccessExitStatus=. If set to on-failure the
> > > >            service will be restarted when the process
> > > >            exits with an nonzero exit code, is terminated
> > > >            by a signal (including on core dump), when an
> > > >            operation (such as service reload) times out,
> > > >            and when the configured watchdog timeout is
> > > >            triggered. If set to on-abort the service will
> > > >            be restarted only if the service process exits
> > > >            due to an uncaught signal not specified as a
> > > >            clean exit status. If set to always the
> > > >            service will be restarted regardless whether
> > > >            it exited cleanly or not, got terminated
> > > >            abnormally by a signal or hit a timeout.
> > > > [/quote]
> > > > 
> > > > I tend towards saying 'on-failure' here.
> > > 
> > > I agree. we defiantly want restart in the 'on-failure'
> > > cases.
> > 
> > Would 'on-failure' mean that libvirtd is to be restarted if it has
> > exited with an error due to wrong configuration? This may spell nasty
> > thrashing of systemd.
> 
> You could get thrashing no matter what setting you use here - eg it
> could be core dumping during startup which would hit with on-abort.
> 
> It doesn't matter though because systemd has rate limiting. By default
> services which are started more often than 5 times within 10s are not
> permitted to start any more times until the 10s interval ends.
> 

It is also possible to exclude certain exit codes or signals
from the restart behavior using RestartPreventExitStatus=

> 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 :|
> 




More information about the libvir-list mailing list