1 files changed, 0 insertions, 71 deletions
diff --git a/results/classifier/deepseek-1/output/hypervisor/1217339 b/results/classifier/deepseek-1/output/hypervisor/1217339
deleted file mode 100644
index b8ee3632..00000000
--- a/results/classifier/deepseek-1/output/hypervisor/1217339
+++ /dev/null
@@ -1,71 +0,0 @@
-
-SIGQUIT to send ACPI-shutdown to Guest
-
-When qemu receives SIGQUIT, it should first try to run system_powerdown (giving the guest an ACPI signal to begin the shutdown process), before ending the whole qemu process.
-
-At this point there is no way to do a graceful shutdown if you do not have access to the monitor and you do not use any wrapper like libvirt.
-
-If, for some reason SIGQUIT would not be accepted as the signal, take any free to use signal, like SIGUSR1. There should be a way to get ACPI shutdown sent to the guest.
-
-On 08/27/13 14:29, Lasse wrote:
-> Public bug reported:
-> 
-> When qemu receives SIGQUIT, it should first try to run system_powerdown
-> (giving the guest an ACPI signal to begin the shutdown process), before
-> ending the whole qemu process.
-
-I strongly disagree. SIGQUIT is an interactive debugging signal. It is
-there so that the user running qemu can trigger a core dump from the
-terminal, when he/she notices a problem.
-
-http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html#index-SIGQUIT-2854
-
-> At this point there is no way to do a graceful shutdown if you do not
-> have access to the monitor and you do not use any wrapper like libvirt.
-> 
-> If, for some reason SIGQUIT would not be accepted as the signal, take
-> any free to use signal, like SIGUSR1. There should be a way to get ACPI
-> shutdown sent to the guest.
-
-What's wrong with SIGINT / SIGTERM? Those signals are there to request a
-clean shutdown (from the terminal and from an unrelated process,
-respectively).
-
-As far as I can see, both SIGINT and SIGTERM end up in
-qemu_system_shutdown_request() on POSIX:
-
-termsig_handler() [os-posix.c]
-  qemu_system_killed() [vl.c]
-    qemu_system_shutdown_request()
-
-Laszlo
-
-
-
-Here is a short patch making Qemu to properly power off the guest when receiving a SIGHUP signal.
-
-I do not think that the way SIGTERM is handled should be modified as it is needed to ask Qemu to forcefully close an unresponsive guest without having to SIGKILL Qemu itself. Regarding SIGINT this is mostly a matter of user expectation (Ctrl-C result), in doubt I keep the original behavior.
-
-On the other side, SIGHUP has a much flexible definition making it a good candidate for the job.
-
-IMHO I think such feature is really useful as it allows to cleanly close all running VM without having to involve Qemu monitor in any way:
-
-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 fiddle with Qemu monitor to implement step 1 as it must currently be done.
-
-Please do not add patches to the bugtracker. Post them to the mailing list instead. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for information how to contribute a patch.
-
-(and I am also not sure whether SIGHUP is the right signal for this job - the original request was also about SIGQUIT instead)
-
-Sorry Thomas, I was not aware of this page. I checked the CODING_STYLE file present in Qemu source before submitting this, maybe it could be useful to include this URL there.
-
-Meanwhile, for reference the discussion continues there:
-https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html
-
-Regards.
-
-The discussion noted in comment#4 petered out in March 2017. Closing this ticket as "Invalid" (only because LP does not let me use the "Won't Fix" resolution -- the report / feature request may very well have had merit, but apparently a good enough design could not be found).
-