Possible to shut down an s6 service via command rather than signal?

Possible to shut down an s6 service via command rather than signal?

[Brett Neumeier via supervision]

I'm trying to set up supervision for a QEMU virtual machine on a machine that uses s6 and s6-rc for service management. I can certainly stop the VM process by sending it a signal -- it appears that SIGINT, SIGTERM, and SIGPWR all work for this -- but none of those trigger a graceful shutdown of the operating system running in the VM, they just cause QEMU to terminate.

I can tell QEMU to send an ACPI poweroff request to the VM by sending a "system_powerdown" command to the QEMU monitor; the way I have this currently set up, I can do that by simply running a command like:

echo system_powerdown | monitor.in

I'm wondering, is there a reasonably idiomatic way to do this with s6 or s6-rc? Or should I do something like write a wrapper script that catches SIGTERM and converts that into a system_powerdown command like the above? Or is there some other, less kludgy, alternative?

(I'm also pondering patching my QEMU so that I can have it run the same ACPI shutdown routine when it catches a signal, which would be a way of making it play nicely with standard s6 idioms, but I'd *rather* not have to do that.)

Cheers!


-- 
Brett Neumeier <random@freesa.org>

Re: Possible to shut down an s6 service via command rather than signal?

[Carlos Eduardo]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

From a similar Github issue [1], the suggested way of implementing "stop
commands" on top of s6 is running these two commands:

```
s6-svc -O /path/to/service
stop-command
```

I'm not aware of any s6-rc sugar around it.

[1] https://github.com/skarnet/s6/issues/18#issuecomment-693368046

Em qua., 24 de jul. de 2024 14:30, Brett Neumeier via supervision <
supervision@list.skarnet.org> escreveu:

> I'm trying to set up supervision for a QEMU virtual machine on a machine
> that uses s6 and s6-rc for service management. I can certainly stop the VM
> process by sending it a signal -- it appears that SIGINT, SIGTERM, and
> SIGPWR all work for this -- but none of those trigger a graceful shutdown
> of the operating system running in the VM, they just cause QEMU to
> terminate.
>
> I can tell QEMU to send an ACPI poweroff request to the VM by sending a
> "system_powerdown" command to the QEMU monitor; the way I have this
> currently set up, I can do that by simply running a command like:
>
> echo system_powerdown | monitor.in
>
> I'm wondering, is there a reasonably idiomatic way to do this with s6 or
> s6-rc? Or should I do something like write a wrapper script that catches
> SIGTERM and converts that into a system_powerdown command like the above?
> Or is there some other, less kludgy, alternative?
>
> (I'm also pondering patching my QEMU so that I can have it run the same
> ACPI shutdown routine when it catches a signal, which would be a way of
> making it play nicely with standard s6 idioms, but I'd *rather* not have to
> do that.)
>
> Cheers!
>
>
> --
> Brett Neumeier <random@freesa.org>
>

Re: Possible to shut down an s6 service via command rather than signal?

[Laurent Bercot]

>From a similar Github issue [1], the suggested way of implementing "stop
>commands" on top of s6 is running these two commands:
>
>```
>s6-svc -O /path/to/service
>stop-command
>```
>
>I'm not aware of any s6-rc sugar around it.

  Indeed.
  Every long-lived program should have a graceful stop signal, instead
of relying on an external command. That's how Unix has always worked,
and it's a misdesign of qemu not to support that.
  Sorry that the s6 way of handling shutdown commands is kludgy, but
s6 really wasn't designed to accommodate them. :/

--
  Laurent

Re: Possible to shut down an s6 service via command rather than signal?

[Dewayne Geraghty]

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 replaced init with s6-svscan, so here's what I've done, for 
shutdown.sh (and lots of other maintenance things)
s6-rc -v 9 -da -t 10000 change > /dev/console
s6-rc -v 9 -Da -t 20000 change > /dev/console
sync 2>&1 > /dev/console

For .s6-svscan i have scripts to capture signals for:
SIGINT SIGTERM SIGUSR1 SIGUSR2 finish crash
Each does similar things except finish, which perform
sync
umounts
lots of other things (graceful jail shutdown, transmit closed log files) 
and initiates a halt or reboot depending on the signal.

An example of signal capture: .s6-svscan/SIGUSR2
#!/usr/local/bin/execlineb -S0
fdmove -c 2 1
redirfd -wnb 1 /dev/console
foreground { echo Executing SIGUSR2 }
exec /s/scan/.s6-svscan/finish USR2

You should be able to do everything in the context of s6 :)
Good luck.

Re: Possible to shut down an s6 service via command rather than signal?

[Brett Neumeier via supervision]

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>

Re: Possible to shut down an s6 service via command rather than signal?

[Mario Rugiero]

Don't know if it's an option for you, but a quick search shows me Firecracker (an alternative to QEMU) does clean shutdown of VMs when it receives SIGTERM.

Re: Possible to shut down an s6 service via command rather than signal?

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

Brett Neumeier schrob:
> 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

A patch to do that has been available since 2017 at least, but the qemu
developers apparently can't agree to any signal to use. See
https://patchwork.kernel.org/project/qemu-devel/patch/23d89ab3bd16ebf7a864ab75c300de7b@whitewinterwolf.com/
and https://gitlab.com/qemu-project/qemu/-/issues/148 .

Here's a current version with SIGPWR.

HTH,
    Jan

diff --git a/os-posix.c b/os-posix.c
index 43f9a43f3..55fb3999a 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -64,6 +64,9 @@ void os_setup_signal_handling(void)
     sigaction(SIGINT,  &act, NULL);
     sigaction(SIGHUP,  &act, NULL);
     sigaction(SIGTERM, &act, NULL);
+#ifdef SIGPWR
+    sigaction(SIGPWR, &act, NULL);
+#endif
 }
 
 void os_set_proc_name(const char *s)
diff --git a/system/runstate.c b/system/runstate.c
index c833316f6..a75c10aa6 100644
--- a/system/runstate.c
+++ b/system/runstate.c
@@ -680,8 +680,18 @@ void qemu_system_killed(int signal, pid_t pid)
     /* Cannot call qemu_system_shutdown_request directly because
      * we are in a signal handler.
      */
-    shutdown_requested = SHUTDOWN_CAUSE_HOST_SIGNAL;
-    qemu_notify_event();
+#ifdef SIGPWR
+    if (signal==SIGPWR)
+    {
+       powerdown_requested = 1;
+       qemu_notify_event();
+    }
+    else
+#endif
+    {
+       shutdown_requested = SHUTDOWN_CAUSE_HOST_SIGNAL;
+       qemu_notify_event();
+    }
 }
 
 void qemu_system_shutdown_request_with_code(ShutdownCause reason,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Possible to shut down an s6 service via command rather than signal?

[Brett Neumeier via supervision]

On Mon, 29 Jul 2024 19:29:45 +0200
Jan Braun <janbraun@gmx.de> wrote:

> Brett Neumeier schrob:
> > 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
> 
> A patch to do that has been available since 2017 at least, but the qemu
> developers apparently can't agree to any signal to use. See
> https://patchwork.kernel.org/project/qemu-devel/patch/23d89ab3bd16ebf7a864ab75c300de7b@whitewinterwolf.com/
> and https://gitlab.com/qemu-project/qemu/-/issues/148 .

That is wonderful! Thank you so much, Jan!

Cheers,

Brett

-- 
Brett Neumeier <random@freesa.org>