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 <ska-supervis...@skarnet.org> 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. > > > > 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. > > > 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. > > 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. > > > 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" > > > > 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? > > > 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. > > 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. ;) > > (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.) > > Hope this helps, > > -- > Laurent
