Hi, On Thu, 3 Sep 2026 22:53:55 +0200 Jan Braun <[email protected]> wrote:
> Hi, > > Lorenzo schrob: > > if you can confirm whether my idea (below) works or not I'm going to > > include either this or your patch to the next runit upload. > > > something like > > > > > > KillMode=control-group > > > TimeoutStopSec=2 > > > > > > can be used instead: did you already tried something like the > > > above (and it does not work)? > > I didn't try it because it's fundamentally wrong: it will send signals > to *all* processes in the control group, including children of > supervised processes, which should not be killed in this way, but > instead be left alone, to be handled by the supervised processes > themselves. ok, then I'm applying your patch. Only thing to be careful is that I think the service can remain stuck in exectop status for long time if there is some misbehaving runit service that does not stop at all. I think that will result in a systemd timeout of 60 (or 180?) seconds, but I'm not sure... Best, Lorenzo > > One case where that might conceivably make a difference is dhcpcd, > where the supervised master process might still use its privsep > children to do additional teardown work before it kills them. I > haven't tested that hypothesis, however. > > (Of course, it would always be possible to work around > KillMode=control-group for such services by making their ./run file > move them to their own cgroup, and runsv(8) would still DTRT by > virtue of staying in the runit.cgroup and getting the TERM signal. > I'd consider that a hack, tho.) > > > > maybe unrelated, but we may also benefit from > > > > > > SuccessExitStatus=111 > > That seems appropriate. > > cheers, > Jan
