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=-2.3 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1214 invoked from network); 27 Sep 2023 16:09:43 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 27 Sep 2023 16:09:43 -0000 Received: (qmail 32054 invoked by uid 89); 27 Sep 2023 16:10:07 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 32046 invoked from network); 27 Sep 2023 16:10:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1695830977; x=1695917377; bh=vF9tNGxrARS1mePuSf7eXQJ7rZmLVUv/+wJ hcoGVFe8=; b=MavxytQ9M/LPyAyLwdOqXntq9pWI61qMFsTyqqmHokCVTzsUyZI R6ZMO4SRcc7xcjBfCZ74SHB1t7PomvgItbEk+ghwMxK2mUk0fpoa4GH4wSUaFU// Dpjh1xVhwAr/sllKU84h4ao47pgp1ve/soi+9iX+8OvdXzL8/KNBZHNcjhtMIUVo km96xLUfAkZGbKoppSQKWmdtDJXeTmy5pQrqDSufaMc13Thd2c7nVdZtW/bhpM5H dTlUY/7hFfQe0RtpOUQ7YMn37HgrVUYD4lGFDsLIPRhpo/CFZe0mVhq/oz/q1PtE gdSACtykdCEyo0kdN1swtXPUEYLSBgY/ZQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1695830977; x= 1695917377; bh=vF9tNGxrARS1mePuSf7eXQJ7rZmLVUv/+wJhcoGVFe8=; b=i 2i2jft9jL2Kh0Mx8UOcF1nZBbhIquLGcq+Ym1Kn3iI66Xt+CIgQ93diNdHy+hW8s HhrU11/NFpgOpqdu3S2pKtDoy51omXPGNU+khYFgxNXnhskGuuaC0WvMeBvUWNyW t6yTTHljRthjFpYdqWA4cUqX2+98xprZa+DyVG3kS+pLxq++XZ0dur4U5pG+2zQV 8JTURUJDbosZ6/MyiNofD+5Lj3HdP+WGvXESAjCSvwOTe7TIs98Bu21kzNQIaZWS y4rSbS0O2w8E/RVSpjBBbAuGInoxJPnVWQxOGwljmWqDhgD83OMY+kJ5FP4Rdvjo D5rzzzyDtkrXuR2I0NH0g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvjedrtdeggdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttdefjeenucfhrhhomhepufgrmhhuvghlucfjohhllhgrnhguuceoshgrmhhuvghlsehs hhholhhlrghnugdrohhrgheqnecuggftrfgrthhtvghrnhepvdeiuddvueettdfgtdfhge efieegtedtieegjeduleehgedutdeuhedtveffueefnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepshgrmhhuvghlsehshhholhhlrghnugdroh hrgh X-ME-Proxy: Feedback-ID: i0ad843c9:Fastmail Message-ID: <0da6cd6d-0e15-d3f5-8eae-0f862bf41164@sholland.org> Date: Wed, 27 Sep 2023 11:09:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux ppc64le; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: s6-rc-update does not create pipes when already-running service becomes a consumer Content-Language: en-US To: Laurent Bercot , supervision@list.skarnet.org References: <169573880839.4539.10047970009995756240@localhost> From: Samuel Holland In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/26/23 14:23, Laurent Bercot wrote: > >  I agree with all you're saying here... >  ... except that this case makes no sense in the first place. A consumer > and a non-consumer are fundamentally different things. > >  A running service that is not a consumer does not read anything on its > stdin. It runs autonomously. >  A consumer, by essence, is waiting on stdin input, in order to process > it and do something with it. > >  If a non-consumer were to become a consumer, it would mean its very > nature would be transformed. It would not behave in the same way at all. That's not necessarily the case. A service may be a non-consumer but still waiting on input from a socket or named pipe. Converting a pair of services to communicate via an anonymous pipe instead of a named pipe is not a very transformational change. > And so, it makes no sense for it to be the "same" service. It should not > be treated the same way; it should not keep the same name. I would disagree here. There is no reason why the service named "foo" before s6-rc-update and the service named "foo" after s6-rc-update need to be related in any way. The naming convention is the user's policy. After all, s6-rc-update already supports converting a service between a oneshot and a longrun, which is an even more fundamental change. >  So, if anything, the change I would make is, when a non-consumer > becomes a consumer, s6-rc-update just throws an error and exits. That all said, this sounds reasonable, assuming the error can be avoided by using a conversion file.