On Sat, Oct 4, 2014 at 2:50 AM, Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:
>
> For simple services, it's looking good, except for this part:
>
> The "probe to see if it really is installed" is an unfortunate necessity
>> as
>> Debian allows the init.d script to be left in place even when the program
>> is removed, and one of my goals is to support the "drop in and replace
>> SysV
>> init scripts" feature; so this is a rough emulation of that behavior.
>> Yes,
>> the init.d scripts really do silently abort if the program is not present.
>>
>
> Well you really don't want to do this.
>
Ok. It's been removed.
>
> Yes, that means you'll have to edit the post-install and pre-removal
> scripts
> in every service package. I'm afraid there's no way around it: SysV does
> not
> care whether your daemon is "wanted up" or not, so it can get away with
> trying and silently failing, but supervision does, and cannot.
>
Ugh. I'm not familiar with all of the details, but I would hazard a guess
that I would need to contact each and every package maintainer and submit a
patch. At this point it becomes a political/social problem and not a
programming/design problem. Not every maintainer is going to want to go
along.
> Run scripts should work the same for runit and s6. The differences are in
> the way the supervisors themselves work: you'll need porting work, for
> instance,
> if you want control file support (runit-specific) or startup/shutdown
> notification support (s6-specific), but the run and finish files should be
> reusable as is.
I've run with this concept this morning and I like the results. There is
now a consistent schema in place for the templates, with .log, .run, and
.finish directories, each holding the template scripts for whatever
log/run, run, and finish scripts are needed. Already I've moved over two
definitions to this arrangement in just minutes.
Still working on that s6 image, although I took the time to read over the
service directory page at
http://skarnet.org/software/s6/servicedir.html,
so I could make sure I understood the implications. At some point, this
might diverge into three projects - a single, universal-scripts project
(for run/finish/log), a project for runit's needs, and a project for s6's
needs. For now, I'll just shuttle the scripts between the two and keep
them in sync.
Lastly, I've run into two scripts that have service dependencies. I have
the urge to make a .run/ template for them as well, called
dependent-service, which would load a list of service names from a
./depends-on file (in the same way that ./options stores the option
flags). The contents of the file would simply be the name of each
service. The script would then use a for-loop to iterate each service
name, doing a "sv start $servicename || exit 1" or "s6-svc -u $servicename
|| exit 1" each time. If I want to get real fancy, I could abstract away
the service start into "$servicestart $servicename || exit 1" and make
dependent-service portable between both projects, but I'm already getting a
bit unwieldy with scripts everywhere, and I'm trying to keep the number of
them down where possible.
Also, I'm still contemplating how to tackle error notification, so for
example, if .run/dependent-service fails because a service dependency, yes
it will be silly and loop, but at least it will yell to the admin "I'm
having trouble" while it's looping.
I like the idea, but I think it could be better. Service dependency could
be done with state tracking, and that suggests that it should be in C and
not in shell script. But state tracking usually implies memory allocation,
and that runs contrary to some of the design goals for the supervision
programs. The inclusion of state tracking in C is probably best discussed
in a separate thread.
Received on Sat Oct 04 2014 - 17:05:09 UTC