supervision-scripts, 2015-03

From: Avery Payne <>
Date: Wed, 01 Apr 2015 17:59:58 -0700

March continues to be a busy month. Most of the work done was internal,
although a few definitions managed to make it out the door.

- - - - - - - -
+ New definitions: redis-server, ahcpd, mongodb, quake-server, famd,
gunicorn, mdadm

+ Revised definitions: rpcbind (now includes a ./check script from Luke
Diamand, thanks!)

+ The logging schema has been fleshed out to support daemontools and
s6. It remains untested at the moment.

+ New! Experimental option for logging called "autolog", a script that
guesses at the logging to be used by looking at the framework in use.
This option is not enabled by default and is considered experimental.
If it works well, it may become the new default and replace the current
policy of setting the sv/.log/run symlink to /bin/true.

+ Took a first pass at splitting up documentation into separate files.
I also updated some of the troubleshooting documentation as it was
referring to removed code.

+ Cleaned up remaining scripts, code, comments, and naming conventions.

In Progress:
- - - - - - - -

+ More definitions! For instance, I'm sitting on a pile of patches for
rpc-related services (read: support for NFS) and it still needs to cook
a bit more before it's done.

+ The only non-template definitions left are: autofs, bind, bluetoothd,
dbus, dhcpd, lwresd, postfix, wicd, and ypbind. They all need some

+ 3 services have broken flags: munin-node, quake-server, and
redis-server. Munin has structural issues, quake-server and
redis-server need additional configuration.

+ Design notes. I took an initial stab at it but I don't like the
structure/layout. Not enough "why", too much "the history of it means
X". Needs more refinement.

+ Clean up untested definitions, as part of the push for the 0.1
release. Many of the definitions have met the minimum test requirements
and I've not cleared out the "untested" marker. The current criteria
for being tested is (a) the service launches cleanly (b) the service
does not complain beyond warnings in its logs (c) the service appears to
function as intended.

+ ...and of course, enough new definitions to justify a 0.1 release.
This means at least 122 *tested* entries in sv/ must be present, which
is about 10% of the count of init.d scripts used by Debian 7. There are
currently 96 entries but many are for getties, so after deducting 18
redundant entries that leaves 78 definitions, which means I need to make
44 entries. Worst case, I end up with a 0.1 release candidate.

Still To-Do / Experimental:
- - - - - - - -
+ Think about ways to incorporate perp, which uses a different format of
./run file. With the recent switch to support /bin/sh vs execline, this
is a real possibility now. That means sv/.run/run-sh,
sv/.run/run-execline, and now sv/.run/run-perp will become potential
targets for sv/.run/run. Madness, I tell you, madness!

+ Examine nosh. This is going take a bit of time to digest...

+ Re-think/re-work the ./needs directory. While nosh already has a
similar concept, I want to be able to support Laurent's future efforts
as well.

+ Prepare to re-license the project as BSD when I approach the 0.2
release, or approximately 244 entries. The entire point of the current
MPL2.0 license was to make contributions "sticky" enough to the project
until such point that it had some critical mass. When I reach over 240+
definitions, the project should be able to accommodate the needs of a
majority of people, so I won't have the same kind of need anymore, and
can re-license the scripts to something much more permissive.

+ Once my project is BSD licensed, I might be able to merge / hybridize
/ collaborate-on some of Toki's work (see below), completely supplanting
the existing sv/.run/run-sh arrangement. Or not. Or, something...we'll
just have to wait and see.

+ Support a modified version of usersv[1]. While scripted support for
user-defined process management will still be present, it would be nice
to see usersv expanded to support other frameworks, and not just runit
alone. This would give a passive (admin controlled) or active (user
controlled) option.

Received on Thu Apr 02 2015 - 00:59:58 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC