[Bug,1217339] Unix signal to send ACPI-shutdown to Guest

Commit Message

Simon March 15, 2017, 1:45 p.m. UTC

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 <[e-mail]>
---
--

Comments

Daniel P. Berrangé March 15, 2017, 2:41 p.m. UTC | #1

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 <[e-mail]>
> ---
> 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

Patch

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();
  }