qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon
Subject: [Qemu-devel] [Bug 1217339] [PATCH] Unix signal to send ACPI-shutdown to Guest
Date: Wed, 15 Mar 2017 14:45:57 +0100
User-agent: Roundcube Webmail/1.1.2

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

--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]