Re: [Qemu-devel] [Bug 1217339] [PATCH] Unix signal to send ACPI-shutdown to Guest

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 02:45:57PM +0100, Simon wrote:
> Hello,
> 
> Here is a short patch answering to Qemu wish-list issue 1217339.
> <https://bugs.launchpad.net/qemu/+bug/1217339>
> It makes Qemu to cleanly power off the guest when receiving a SIGHUP
> signal, thus without requiring any monitor access which is currently
> impossible (AFAIK).
> 
> The original issue mentions using SIGQUIT in its title, however as
> Laszlo explained in the bug thread SIGQUIT is designed for debugging
> purposes and is less about quitting than generating a core file. The
> original request also explicitly mentioned that:
> 
> > If, for some reason SIGQUIT would not be accepted as the signal, take
> > any free to use signal, like USR1.
> 
> Qemu currently maps SIGTERM, SIGINT and SIGHUP to a brutal shutdown of
> the guest. This patch does not alter Qemu behavior for SIGTERM and
> SIGQUIT, and maps SIGHUP to the clean power off of the guest.
> 
> IMHO SIGTERM and SIGINT behavior should not be altered:
> 
> - SIGTERM is the preferred alternative to a SIGKILL to shutdown a stuck
>   guest.
> - SIGINT is mostly a matter of user expectation as it handles the Ctrl-C
>   sequence, I suppose that most users expect a brutal shutdown as it is
>   now but this is just a random guess.
> 
> SIGHUP is a more versatile signal, also used for instance to tell a
> daemon to reload its configuration files. From a functional point-of-
> view, for me it makes sense to use a "hang-up" signal to power off a
> guest, more than an impersonal USR1 signal, but this remains easily
> changeable would SIGHUP not be suitable for this purpose.
> 
> With this patch applied, it becomes possible to easily and cleanly shut-
> down Qemu virtual machines system-wide without involving any monitor:
> 
> 1. Send SIGHUP to all Qemu processes so the guests power off cleanly.
> 2. After a few time send SIGTERM to the remaining Qemu processes to
>    forcefully close stuck guests.
> 3. After a few time send SIGKILL to the remaining Qemu processes to
>    forcefully close stuck Qemu hypervisor processes.
> 
> I find this more convenient than having to tinker with Qemu monitor to
> implement step 1 as it must currently be done.
> 
> Signed-off-by: Simon Geusebroek <address@hidden>
> ---
> diff -ur a/vl.c b/vl.c
> --- a/vl.c    2016-12-20 21:16:54.000000000 +0100
> +++ b/vl.c    2017-03-14 16:02:51.959911847 +0100
> @@ -1871,7 +1871,11 @@
>      /* Cannot call qemu_system_shutdown_request directly because
>       * we are in a signal handler.
>       */
> -    shutdown_requested = 1;
> +    if (signal == SIGHUP) {
> +        powerdown_requested = 1;
> +    } else {
> +        shutdown_requested = 1;
> +    }
>      qemu_notify_event();
>  }

While I understand your motivation this creates a semantic change for
existing users of QEMU. IOW anyone who is currently relying on use
of SIGHUP will experiance a regression when upgrading QEMU.

So if we want to signal to generate a clean shutdown, we need to pick
one that QEMU hasn't already set a specific behaviour for.

SIGQUIT could be a valid option, or the super generic SIGUSR1

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|