From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 23192 invoked from network); 15 Feb 2022 01:26:25 -0000
Received: from alyss.skarnet.org (95.142.172.232)
  by inbox.vuxu.org with ESMTPUTF8; 15 Feb 2022 01:26:25 -0000
Received: (qmail 7830 invoked by uid 89); 15 Feb 2022 01:26:45 -0000
Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm
Sender: <supervision@list.skarnet.org>
Precedence: bulk
List-Post: <mailto:supervision@list.skarnet.org>
List-Help: <mailto:supervision-help@list.skarnet.org>
List-Unsubscribe: <mailto:supervision-unsubscribe@list.skarnet.org>
List-Subscribe: <mailto:supervision-subscribe@list.skarnet.org>
List-Id: <supervision.list.skarnet.org>
Received: (qmail 7823 invoked from network); 15 Feb 2022 01:26:45 -0000
X-Virus-Scanned: SPAM Filter at disroot.org
Date: Tue, 15 Feb 2022 02:26:08 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail;
	t=1644888376; bh=vor1kIHXWlpwcd4ZtEuOhHWyjeDzOrcp5FjrQACL48Y=;
	h=Date:From:To:Subject;
	b=LeqzVxB2PIkw08y4YvZ5PSB6uKhztXm+GSRn1g2h8F+Egq/TczOBO5Uo60b2/d061
	 d/p8fED0FdKHWkK/bazrjQXCYq32ZJxvICmwnyh1L3x4IwVbxdFq54Sa7wnMGZuRSy
	 sNhLhV+XxHeUbn54urJApPcdKxHE6KkAqKTw4rg5Ru9taQFR062U6hZxK2DBLxCdNW
	 rwSe+6MOfSN19x+DiMpNg7FNeRvdSy3FWUTXnKVBbaJSeF/+6Dcs186gBdtuLNycQ+
	 yDbcXizUTFKRJpyjiuxhwQ4u3Sm27N6na4yw5+qeUdyzfCsXhcUrAR7Avb3QOALnXk
	 QUsU7USJYlVEA==
From: Lorenzo <plorenzo@disroot.org>
To: supervision@list.skarnet.org
Subject: runit: runsv(8) incorrect regarding control/[dx]
Message-ID: <20220215022608.05b063fa@lorenz.fritz.box>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


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