From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: from alyss.skarnet.org (alyss.skarnet.org [95.142.172.232]) by inbox.vuxu.org (Postfix) with SMTP id D271E23A6C for ; Thu, 25 Jul 2024 18:27:02 +0200 (CEST) Received: (qmail 16804 invoked by uid 89); 25 Jul 2024 16:27:27 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 16797 invoked from network); 25 Jul 2024 16:27:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freesa.org; s=20240612; t=1721924818; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Qd0+yjbEGyBdi7dUfOf0tCzmSH7+DqPyXYA9zEqkGzw=; b=jAqF5AFlMU2kebADfx26BJEAIXbBitz1Rt4OH6EI9pp15/E+ZP09fOMh4RDcBg08ltTUOJ akOXwNxzghyLv2gfAN5JjSsSTdD2DNxDG5hrwZLAAVRc8A5ZJDKMobYxTPQCeSs5AE9f3a Dpir1XJp3GOje31ZzbMXT/gYzpe6Vzc= Date: Thu, 25 Jul 2024 11:26:55 -0500 From: "Brett Neumeier via supervision" Reply-To: Brett Neumeier To: Dewayne Geraghty Cc: supervision@list.skarnet.org Subject: Re: Possible to shut down an s6 service via command rather than signal? Message-Id: <20240725112655.586841fef892611b74fa22bb@freesa.org> In-Reply-To: <4664aee1-4ae5-4abb-b02a-3520b259655d@heuristicsystems.com.au> References: <20240724123027.8c04a742f5ee892725c2120f@freesa.org> <4664aee1-4ae5-4abb-b02a-3520b259655d@heuristicsystems.com.au> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 25 Jul 2024 11:15:41 +1000 Dewayne Geraghty 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