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 <qemu.b...@whitewinterwolf.com> > --- > 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/ :|
