Hello Fellow Supervision Users,
I've just released r14 the other day when I've just released r13 the day
before
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
if
there wasn't any before. Standard LSB commands, namely {start,stop,status,-
reload} and extra commands {add,remove,desc,cgroup_remove_service} are
supported.
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:
--[/etc/sv/atd/OPTIONS--
SVC_OPTS='-f -d'
SVC_USER=at
SVC_GROUP=at
SVC_SPOOLDIR=/var/spool/at
pre()
{
checkpath -q -d -m 1770 -o ${SVC_USER}:${SVC_GROUP}
${SVC_SPOOLDIR}/atjobs
checkpath -q -d -m 1770 -o ${SVC_USER}:${SVC_GROUP}
${SVC_SPOOLDIR}/atspool
}
--[END OF FILE]--
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...
--[/etc/sv/xinetd/OPTIONS]--
SVC_CONFIGFILE=/etc/xinetd.conf
SVC_OPTS='-f ${SVC_CONFIGFILE} -dontfork -stayalive'
pre()
{
[ -f ${SVC_CONFIGFILE} ]
}
--[END OF FILE]--
The configuration file check would suffice... if it fails, xinetd service
would be
removed from `/service/' and running '/service/' (`/etc/service' &
`/run/service'
respectively) to prevent any attempt to restart the service which is not
necessary
in this case.
I was saying _done_ because there nothing more to do to ease life but bug
fixes.
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
not,
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
CGroup.
The remaining--in CGroup--is... put daemon supervisors in CGroup. This is
not
really an issue since this can be done with cgred service with something
like:
--[/etc/cgroup/cgconfig.conf]--
group supervisor {
"name=supervision" {
}
}
--[END OF FILE]--
--[/etc/cgroup/cgrules.conf]--
*:runsv supervision supervisor/
--[END OF FILE]--
[Replace `runsv' with `supervisor' for daemontools[-encore] or
`s6-supervise'.]
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.)
TODO: DONE.
Enjoy easy supervision.
--
Error 404: gentoo user <0123456789> was not found
Received on Sat Mar 07 2015 - 08:03:50 UTC