>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 - 10:53:47 CET