Control: tags -1 moreinfo Hi Jan,
thanks for reporting this. I don't use runit-run (and systemd) so the package relies on report from users On Wed, 19 Aug 2026 16:52:34 +0200 Jan Braun <[email protected]> wrote: [..] > > This works properly for startup. However, there's a race condition on > shutdown: > > The runit.service is defined with > | KillSignal=SIGHUP > | KillMode=process > which causes systemd to send SIGHUP to the runsvdir. Quoting > runsvdir(8): > | If runsvdir receives a HUP signal, it sends a TERM signal to each > | runsv(8) process it is monitoring and then exits with 111. > ...and that is exactly what it does. In particular, runsvdir does NOT > wait for the runsv processes to exit first, hence the runit-supervised > services may not have terminated (or even gotten SIGTERM) yet. > > But systemd (in KillMode=process) assumes that runsvdir exiting means > the service is down, and proceeds to stop the dependencies. Depending > on timing, this breaks my still-running (or still-shutting-down) > services. > > I wish for this race to be fixed. :) OK > > I can see 2.5 ways to do that: > 1) It should be possible to teach runsvdir to wait for its runsv > children to exit before exiting itself. And since runsv in turn > does wait for its children to exit, that would ensure the whole > supervision tree has exited when runsvdir does, as systemd expects. > 2) It is possible to use systemd's ExecStop= configuration to delay > systemd from considering the service stopped until the process > specified there has exited. Hence, specify a process that waits for > the supervision tree to die. > 2a) You could do so by interacting with > /etc/runit/runsvdir/svmanaged/*/supervise/ to find the processes > in question, or > 2b) since systemd puts each service in its own cgroup, you can wait > for that cgroup to become empty. > > While I think 1) would be cleaner, I'm unsure about the compatibility > implications (Change SIGHUP behaviour? Use a new signal? Would Debian > want to patch runsvdir like that?) now that upstream is active again I prefer not to carry additional Debian specific patches, so this would be better discussed upstream. > and the reason for the current > runsvdir behaviour (When/why is not waiting ever useful?). > If you think some version of this would be a good feature, please say > so, and I'll try to come up with a patch. let's first try to address this without patching runit > > So meanwhile, I implemented 2b), the resulting ExecStop= script is > attached. It has been working well for me. I hope it's useful, or even > acceptable for inclusion in Debian. I'm ok with this patch, but first I wonder if there is a way to address this with systemd directives (without extra scripts); I don't know why we use KillMode=process , by looking at https://www.freedesktop.org/software/systemd/man/latest/systemd.kill.html?__goaway_challenge=meta-refresh&__goaway_id=f51c50d8745b3678afa63ccfdd4956af something like KillMode=control-group TimeoutStopSec=2 can be used instead: did you already tried something like the above (and it does not work)? maybe unrelated, but we may also benefit from SuccessExitStatus=111 Cheers, Lorenzo
