Hi all,
I'm maintaining runit in Debian and I have a bug report [1] on the customized control of runsv. The standard behavior appears to be that first, files in service/control/ are checked and then, only if they don't exists or return nonzero runsv proceeds to send the appropriate signal. However with control/[dx] the manpage gets more confused and it's not obvious that the code actually does [2] [A] * check for control/t , possibly overriding SIGTERM * SIGTERM (not if control/t returned zero) * SIGCONT (control/c is disregarded) * check and run control/[dx] (does the return code of [dx] have any effect here?) The reporter asks to change the code so that it behave consistently with the standard mechanism, it could look something like [B] * check and run control/[dx] , possibly overriding SIGTERM * check for control/t , possibly overriding SIGTERM (not if control/[dx] returned zero) * SIGTERM (not if control/[dxt] returned zero) * SIGCONT I can't think of a reasonable use case for [B], except that is possible to have a different override for SIGTERM with t and dx commands.. not even sure is a good thing to have this inconsistent behavior. On the other hand I'm not sure of what was the intended use for [dx] in [A]: d or x scripts are like a "special finish file" that is run before the actual finish file, but only when the requested status of the service is WANT_DOWN or WANT_EXIT, with the return code that has no effect? .. Any example/opinion on why [A] is better than [B] or vice versa? Best, Lorenzo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983726 [2] https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L246