[libvirt] [PATCH] Configuring systemd to restart libvirt on abort
----- Original Message -----
On Mon, Jul 29, 2013 at 05:36:21PM +0300, Mooli Tayer wrote:
From: Mooli Tayer <mtayer@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.
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 :|
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@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. Dan.
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@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. 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 :|
----- 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@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 :|
participants (3)
-
Dan Kenigsberg -
Daniel P. Berrange -
Mooli Tayer