On Thu, 25 Jul 2024 11:15:41 +1000
Dewayne Geraghty <dewayne_at_heuristicsystems.com.au> wrote:
> Brett, I had a similar issue. (Please note: I do not use qemu and only
> use FreeBSD/HardenedBSD, with lots of lightweight jails).
>
> I'm surprised you need to write a catcher for signals as that should be
> caught by your init (Id:1) process which should be graceful?
I think there is some misunderstanding? I do not need to write a signal catcher. The only signals being sent in this situation are *by me* or *by s6*. My problem is that QEMU does not have any facility for doing a graceful shutdown of a guest VM in response to _being signalled_; it only does a graceful shutdown of the guest in response to _receiving a command on the QEMU monitor_.
I'm not having any problems with the way that s6 and s6-rc are working in the guest VM. I'm having a problem with supervising the QEMU VM process on the host computer.
It seems like my options are, I can:
1. shut down the service by doing `s6-svc -O` to tell s6 not to restart the QEMU service when it goes down, followed by the command that will tell QEMU to shut down gracefully; or
2. patch QEMU to add a signal handler so that it will gracefully shutdown when it receives a specific signal (and then tell s6 to use that signal to take the service down); or
3. run QEMU through a wrapper that catches a signal and runs the graceful shutdown command, and have s6 run that wrapper script instead of just starting QEMU directly.
I don't think that there's any benefit to changing how s6-svscan handles signals, in my situation. If I'm misunderstanding what it is your setup does and it would actually be helpful for me, please say more words about how! Because so far I'm not seeing it.
Cheers!
--
Brett Neumeier <random_at_freesa.org>
Received on Thu Jul 25 2024 - 18:26:55 CEST