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-supervision_at_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
Received on Wed Jan 11 2023 - 17:08:13 CET