Re: Essex: A simple command line interface for managing s6 services, using the s6 toolset

[Jonathan de Boyne Pollard]

The |cat| subcommand is the one that seems to get most people.  I have 
seen more objections to that in systemd's |systemctl| than to any of the 
others, because it really isn't concatenation as people are used to.  I 
provide it in my toolset because I provide migration paths for people 
familiar with systemd.  I would not have chosen |cat| myself, if I had 
had the choice.  (It is actually |grep| under the covers, not |cat|, for 
starters.)  If you are /not/ looking to have similar commands as a 
systemd migration path, which seems to be the case from the other 
subcommands that you have, you would probably do well to come up with a 
better name than |cat|.


I went with |reset| rather than |sync|. |preset| sets the /enable/ state 
from configuration information. |reset| sets the /start/ state from 
configuration information, and as the manual says can be thought of as 
"reset to however the service is configured to be at bootstrap" with 
respect to start/stop. |sync| is not a bad name, but |system-control| 
 can 
do /system/-level stuff (e.g. |poweroff|) as well as /service/-level 
stuff, and there is a definite quite different meaning to |sync| when 
one is operating at system level which would not be a good idea to 
overlap.  You're providing service management and not system management, 
and contrastingly are probably alright here.


Your |reload| is not what people have come to know and to think of by 
that name, and will probably confuse people. What people have come to 
know by that name is sending a "reload" signal (of some kind, the exact 
signal varies) to the service telling the service to /keep running/ but 
reload stuff. What you have is more akin to what people know as 
|condrestart| or |try-restart|, although it is not quite those either, 
because (for one thing) they do not have the side-effect of starting 
currently stopped services as your |reload| subcommand does.  See the 
Debian /Policy Manual/ 
 
and the Fedora wiki 
 
for the long standing meanings of the |try-restart| and |reload| 
subcommands.


Placing the generation of the information that your |reload| operates on 
actually in the |run| script itself is a bit of a layering violation.  
Really, a framework to detect changes to |run| scripts should have no 
effect on the |run| scripts contents themselves, certainly not the 
requirement that they be modified to inject special extra commands.  You 
end up with user problems, with users setting up vanilla |run| scripts 
that they get from elsewhere 
 
and then not being able to successfully employ your tools on top of 
that.  You end up with mechanism problems, with a /single change/ to a 
|run| script resulting in potentially /repeated/ termination signals (if 
|reload| is called more than once, which people inevitably /will/ do) 
until the part of the |run| script that regenerates the signature 
actually re-runs, and takes.


Observe how I designed service bundles.  They are layered on top of 
|supervise/| and |service/| directories.  Before/after orderings, 
wants/conflicts dependencies, and the rest are all /outwith/ the 
scripts, and do not require modifying them.  Only |system-control| has 
dealings in them.  The scripts, the lower-level |service-control| 
/|svc|, 
and indeed the |service-manager| 
 
itself, have no notion of /any/ of that.  Indeed, it is one of /two/ 
ways of deciding what services to run, the other of which would be 
adversely affected if all of the scripts had to incorporate tooling for 
the first mechanism.  Maintaining layering allows drop-in replacement, 
and the administrator a choice of the |system-control| way or a 
daemontools-style |service-dt-scanner| 
/|svscan| 
way.


Maintaining layering allows further forms of drop-in replacement, too.  
My nosh toolset does not require that |run| scripts use the toolset's 
own chain-loading utilities.  It is just as happy with |run| scripts 
that use execline, or the perp tools, or runit's |chpst|.  The service 
manager only cares that it's a program that it can |fexecve()|. Whereas 
your tooling forces execline for everything, because you've built it 
around having a snippet of execline code embedded in an execline script 
as a part of the mechanism.


For a restart-if-the-|run|-script-has-changed framework, I suggest a 
similar approach.  The simplest approach is surely to have a per-service 
|Makefile.essex|, or a set of redo |.do| scripts, that embodies the 
if-file-X-changed-take-action-Y 

Essex: A simple command line interface for managing s6 services, using the s6 toolset

[Andy Kluger]

Hello!

s6 is great, but its existing interface can feel a bit unwieldy for
me, and I need to re-read the docs frequently. So I've made a command
line frontend with helper functions for it, called essex:

on GitHub: https://github.com/AndydeCleyre/essex

video demo: https://streamable.com/oek3d

on PyPI: https://pypi.org/project/essex/

I hope someone else will also find it useful.

Here's an example runfile and loggerfile generated by the tool:

```
==> /home/andy/svcs/memdb/run <==
#!/bin/execlineb -P
fdmove -c 2 1   # Send stderr to stdout
foreground { redirfd -w 1 run.md5 md5sum run }  # Generate hashfile,
to detect changes since launch
s6-setuidgid redis  # Run as this user
cd /var/lib/redis   # Enter working directory
redis-server# Do the thing


==> /home/andy/svcs/memdb/log/run <==
#!/bin/execlineb -P
foreground { redirfd -w 1 run.md5 md5sum run }  # Generate hashfile,
to detect changes since launch
s6-log  # Receive process output
  T # Start each line with
an ISO 8601 timestamp
  s4194304  # Archive log when it
gets this big (bytes)
  S41943040 # Purge oldest
archived logs when the archive gets this big (bytes)
  /home/andy/svcs-logs/memdb# Store logs here
```

It lends itself to aliases like:

`alias sussex="sudo essex -d /var/svcs"`

Thanks of course to skarnet for the excellent software that does all
the work, in a sane way, as well as the frequent immediate support and
feedback.

Essex does not (at least, not yet) offer any conveniences for
interdependence of processes, but for my cases thus far the usual
retry behavior is sufficient. I welcome advice on growing or otherwise
improving the project, if there's interest.

Please let me know if you try it! Feel free to submit issues, or reach
me on Telegram: https://t.me/andykluger , as I'm awful at noticing
emails from real humans.