supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* s6 vs shell wrappers for client connections
@ 2023-01-10 22:23 artur.brzozowski
  2023-01-11  9:53 ` Laurent Bercot
  2023-01-11 20:15 ` Steve Litt
  0 siblings, 2 replies; 5+ messages in thread
From: artur.brzozowski @ 2023-01-10 22:23 UTC (permalink / raw)
  To: supervision

Hi.

I'm wondering if and how s6 can help with the following
user-oriented problem:

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.

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? The goal is to always run the program correctly: if
server is available, connect to it with client binary, if not -
use the standard one.

In a not-so-old issue thread [1] I read:
>
> User: st3r4g
> For example, with s6-rc you would have a foot server service
> running foot -s -p 3 and have notification-fd set to 3 in the
> service directory. Then you can have e.g. footclient irssi
> depend on the foot server service, and they will all be started
> in the correct order, as soon as possible.
>
> User: dnkl
> The --print-pid option was designed with s6 in mind ;)

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?

Any pointers, even to the correct man page for this, would be
appreciated.

Best wishes,
Artur

[0] https://codeberg.org/dnkl/foot
[1] https://codeberg.org/dnkl/foot/issues/604#issuecomment-267617


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6 vs shell wrappers for client connections
  2023-01-10 22:23 s6 vs shell wrappers for client connections artur.brzozowski
@ 2023-01-11  9:53 ` Laurent Bercot
  2023-01-11 16:08   ` artur.brzozowski
  2023-01-11 20:15 ` Steve Litt
  1 sibling, 1 reply; 5+ messages in thread
From: Laurent Bercot @ 2023-01-11  9:53 UTC (permalink / raw)
  To: supervision

>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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6 vs shell wrappers for client connections
  2023-01-11  9:53 ` Laurent Bercot
@ 2023-01-11 16:08   ` artur.brzozowski
  0 siblings, 0 replies; 5+ messages in thread
From: artur.brzozowski @ 2023-01-11 16:08 UTC (permalink / raw)
  To: Laurent Bercot; +Cc: supervision

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@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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6 vs shell wrappers for client connections
  2023-01-10 22:23 s6 vs shell wrappers for client connections artur.brzozowski
  2023-01-11  9:53 ` Laurent Bercot
@ 2023-01-11 20:15 ` Steve Litt
  2023-01-12  0:51   ` Laurent Bercot
  1 sibling, 1 reply; 5+ messages in thread
From: Steve Litt @ 2023-01-11 20:15 UTC (permalink / raw)
  To: supervision

artur.brzozowski said on Tue, 10 Jan 2023 22:23:32 +0000

>How, if at all, could s6
>help remove this executable ambiguity, the need for checking and
>wrapping? The goal is to always run the program correctly: if
>server is available, connect to it with client binary, if not -
>use the standard one.

if s6-svstat myserver; then
  client_binary
else
  send_email_to_admin
  faux_client_binary
fi

or:

[ s6-svstat myserver ] && exec client_binary
send_email_to_admin
exec faux_client_library

I guess the preceding scripts qualify as a "wrapper scripts", but
they're pretty innocuous. The second one doesn't even leave a trace
that it was ever a shellscript.

As Laurent mentioned, the s6/runit/Daemontools philosophy is to assume
the server's running because Daemontools-inspired process supervisors
are so robust, but if your client must be available no matter what,
even when the server is deliberately taken down for replacement or
servicing or troubleshooting, then for sure a Plan B is a good thing.

SteveT

Steve Litt 
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6 vs shell wrappers for client connections
  2023-01-11 20:15 ` Steve Litt
@ 2023-01-12  0:51   ` Laurent Bercot
  0 siblings, 0 replies; 5+ messages in thread
From: Laurent Bercot @ 2023-01-12  0:51 UTC (permalink / raw)
  To: supervision

>if s6-svstat myserver; then
>   client_binary
>else
>   send_email_to_admin
>   faux_client_binary
>fi

  Please don't do this.

  - As Steve would be able to tell you if he had read the documentation
page for s6-svstat (https://skarnet.org/software/s6/s6-svstat.html),
"s6-svstat myserver"'s exit code does not mirror whether myserver is
running or not. If myserver is a live service directory, s6-svstat
will print a line to stdout summarizing the status of the service,
then exit 0. Zero, even if the service is down, so client_binary
will fail.
  s6-svstat will only exit nonzero if an error occurs or if no
supervisor is running on myserver, which is not what this script
aims to test.

  - It is good to notify the admin when something on the system is not
working correctly. Doing it automatically from a script, however, is
not a good idea. Spamming the admin's mailbox via automated messages
is an great way to get yourself ignored at best (which defeats the
purpose of reporting bugs) or banned at worst.

  - If you're using s6, as I said earlier, you're supposed to be able
to assume that myserver is running, and you don't have to write
such wrappers, even ones that would work.

--
  Laurent


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-01-12  0:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-10 22:23 s6 vs shell wrappers for client connections artur.brzozowski
2023-01-11  9:53 ` Laurent Bercot
2023-01-11 16:08   ` artur.brzozowski
2023-01-11 20:15 ` Steve Litt
2023-01-12  0:51   ` Laurent Bercot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).