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,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8465 invoked from network); 11 Jan 2023 16:08:31 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 11 Jan 2023 16:08:31 -0000 Received: (qmail 27998 invoked by uid 89); 11 Jan 2023 16:08:52 -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 27988 invoked from network); 11 Jan 2023 16:08:52 -0000 Date: Wed, 11 Jan 2023 16:08:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1673453304; x=1673712504; bh=H4ESeoZl+Euc5pbyZdHGw1dOuDNCzPFREKmI1Hb6R3c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=lkDvR9lRwDb/AnTJ3pYezloXYmhvzeNA8iw01Z74pAK6vgh2zhG9iBS0LjtqFjIbp kGj3f1feg40zTfQLDxy/lqQtiM63esqC7P5npDtZruBysM430J899ODyoKLY71e3yR 3+6Ttym0oR9D5mGODSbpJ8MxfQAdQezyxoRt2Ni6SEOy9N649qibe6RWpA0xeQJeLz au0g4CvTylimhXgQH1RNpY1eP/PmZ63mbeJYWWOIt7k4otSuCbFijuIoAR67neMZJf NlPo/bop80m0yHviWue7+u+0pf5ilOxLC8qNFIiFjPIMa4hZlH6op0tRtpYtdRMFg7 NPc/N/3h4lSPg== To: Laurent Bercot From: "artur.brzozowski" Cc: "supervision@list.skarnet.org" Subject: Re: s6 vs shell wrappers for client connections Message-ID: <2-7sa52YXFLxHiPArXNnjI9ORNlAXvYHhudEP9V6-BVlPncN8ElwGtJ526YHKSNgLBsy2nUajcMPKpAJJqJY2LSLM50VISPLCibWKdnbQGw=@protonmail.com> In-Reply-To: References: Feedback-ID: 11846861:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, Laurent. Your message helps clear some misunderstandings I had due to incomplete knowledge and the state we are in when it comes to process supervision. It's not easy to know what things *could/should* look like in a world where a lot of software uses bad design that sets bad expecations. Let me also thank you for writing this software - it's an effort that's nothing short of titanic. Regards, Artur On Wednesday, January 11th, 2023 at 9:53 AM, Laurent Bercot wrote: > > You have a program that can be started normally or as a service > > that accepts connections through a socket. For client > > connections, an additional binary is supplied. > >=20 > > The simplest way to make sure that the program launches > > regardless of whether there's a server running or not is a > > wrapper script that executes the right binary based on socket's > > availability. >=20 >=20 > In a vacuum, for a generic client, yes. > On a machine you control, there is a simpler way: by policy, you > should know if a server is available or not. >=20 > s6 won't help you much with making a client that works in uncertain > situations. What it will help you with, however, is reduce the unknowns > on a machine you use it with. In this case, it can ensure that you > know, by policy, that a given server is running, so you can assume > its presence - and if the assumption is wrong, it's a bug, and the > machine's admin should fix it. >=20 > > Example of this is the 'foot' terminal emulator - it has 'foot > > [--server]' and footclient binaries. How, if at all, could s6 > > help remove this executable ambiguity, the need for checking and > > wrapping? > > (...) > > To continue with the example: I set up 'foot' as described above. > > The result is that s6-svscan/supervise starts the 'foot' server, > > places an 'S' socket in the service directory and sits there. I > > can connect to the server by pointing to socket in service > > directory > > $ footclient -s "$s6-foot-servdir/S" > >=20 > > This however, still requires me to check for the socket and > > if-else the binary and options each time I want to start the > > program, doesn't it? Does s6 offer a remedy? >=20 >=20 > If you're running a machine with an s6-supervised foot service, then > the point of it is that the foot server is always running. The > supervision tree will start it at boot time, and maintain it through > the machine's lifetime: so, the footclient invocation is always the > correct way to run a client. You don't have to plan for the case > where there's no server: if there's no server, it's a bug, and outside > the responsibility of the client to plan for. >=20 > If you don't want to have a server permanently listening to a socket, > then don't add a supervised service; but in this case, you will have > to deal with the unknown state of your machine, and script your client > so it spawns a server as needed. Needless to say, I think that's a > technically inferior solution. ;) >=20 > (We had a good IRC discussion not long ago about the merits and > drawbacks of on-demand server spawning. My point of view is that > on-demand isn't nearly as useful as people pretend it is, because you > provision a server for max charge anyway, and idle services do not > consume resources - so on-demand spawning does not increase the > power of your setup, it only increases its flexibility, which is > very overrated on most modern setups which are, for better or worse, > built for a fixed set of tasks.) >=20 > Hope this helps, >=20 > -- > Laurent