[ANNOUNCE] Supervision Scripts Framework r14

From: toki clover <tokiclover_at_gmail.com>
Date: Sat, 7 Mar 2015 09:03:50 +0100

Hello Fellow Supervision Users,

I've just released r14 the other day when I've just released r13 the day
that... and thought it was, finally, the last, again.

Well, I made a few tests before pushing the commits, but not really what was
necessary in _normal_ functioning state in a installed variant.

Anyway, r14 followed suite and this release was roughly +50/-30
(lines addition/removal) like r13. Sheer bug fixes and stabilization
putting the
last bits tightly together.

Well, I'm done then! More on this later.

There is a simple script `sv/.opt/svc' which has LSB like commands that can
be used to manage and add services e.g. `/etc/sv/.opt/svc add --log atd'.
It does support a list of services as well, so adding a batch of services
is also
supported. If used as an automated task, add `--check' switch then.

The same commands are also supported when using a service instead, e.g.
`/etc/sv/acpid/run add --log' would add a logging support to acpid service
there wasn't any before. Standard LSB commands, namely {start,stop,status,-
reload} and extra commands {add,remove,desc,cgroup_remove_service} are

This framework aims to provide an easy way to supervision and not a huge
collection of services because adding new ones is very easy. The only thing
remaining to take care is the foreground and logging choice. This is why a
syslog service was added early (using syslog-ng as a backend.)

Many daemons run in the foreground and use a logger facility by default.
In the previous example, a simple file `OPTIONS' file like:
SVC_OPTS='-f -d'

    checkpath -q -d -m 1770 -o ${SVC_USER}:${SVC_GROUP}
    checkpath -q -d -m 1770 -o ${SVC_USER}:${SVC_GROUP}
would suffice to have a functional service. Notice the foreground arguments
and the pre() function to take care of the setup of the daemon.

Many daemons require a configuration file and that's all about it. This is
even simpler to do...
SVC_OPTS='-f ${SVC_CONFIGFILE} -dontfork -stayalive'

    [ -f ${SVC_CONFIGFILE} ]
The configuration file check would suffice... if it fails, xinetd service
would be
removed from `/service/' and running '/service/' (`/etc/service' &
respectively) to prevent any attempt to restart the service which is not
in this case.

I was saying _done_ because there nothing more to do to ease life but bug

Every command executed with `/etc/sv/SERVICE/run COMMAND' are managed
with Control Groups in Linux. At first, only the daemon and log command was.
I thought of removing those noises first... but if CGroup is supported or
the noises are cheap with very few tests to set up or not (disabled/enabled)
CGroup. And `sv/.opt/svc COMMAND' offers a variant without the said noises.
So, keeping it as is. And it may makes sense to contain everything in

The remaining--in CGroup--is... put daemon supervisors in CGroup. This is
really an issue since this can be done with cgred service with something
group supervisor {
    "name=supervision" {
*:runsv supervision supervisor/
[Replace `runsv' with `supervisor' for daemontools[-encore] or
Or else... should I start thinking about dirty hacks to include it? Wait,
keep it
simple and sane! (This was part of the design from day one.)


Enjoy easy supervision.

Error 404: gentoo user <0123456789> was not found
Received on Sat Mar 07 2015 - 08:03:50 UTC

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