From: "Brett Neumeier via supervision" <supervision@list.skarnet.org>
To: Dewayne Geraghty <dewayne@heuristicsystems.com.au>
Cc: supervision@list.skarnet.org
Subject: Re: Possible to shut down an s6 service via command rather than signal?
Date: Thu, 25 Jul 2024 11:26:55 -0500 [thread overview]
Message-ID: <20240725112655.586841fef892611b74fa22bb@freesa.org> (raw)
In-Reply-To: <4664aee1-4ae5-4abb-b02a-3520b259655d@heuristicsystems.com.au>
On Thu, 25 Jul 2024 11:15:41 +1000
Dewayne Geraghty <dewayne@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@freesa.org>
next prev parent reply other threads:[~2024-07-25 16:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 17:30 Brett Neumeier via supervision
2024-07-24 18:15 ` Carlos Eduardo
2024-07-24 21:09 ` Laurent Bercot
2024-07-25 1:15 ` Dewayne Geraghty
2024-07-25 16:26 ` Brett Neumeier via supervision [this message]
2024-07-25 16:56 ` Mario Rugiero
2024-07-29 17:29 ` Jan Braun
2024-07-30 19:33 ` Brett Neumeier via supervision
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240725112655.586841fef892611b74fa22bb@freesa.org \
--to=supervision@list.skarnet.org \
--cc=dewayne@heuristicsystems.com.au \
--cc=random@freesa.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).