> 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.
Yes, that's been the bane of supervision frameworks from the start - the
way they start and stop services is fundamentally different from the SysV
way, so it does require support from the packager. The adoption of
supervision has always been a political issue, never a technical one. And
the reason why systemd became so prevalent is that the systemd people
applied political pressure; they were much better at that than we were.
You could look at how Alpine Linux does things. As far as I know, it's a
runit-based distribution.
> 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.
That's how things have traditionally been running with supervision schemes.
Just start all the services, and they will fail and get restarted as long as
their dependencies aren't met, so eventually everything will work. It has
the advantage of simplicity: no explicit service dependency tracking is
needed. It has the drawback of being a bit messy, and using more resources
than needed at startup time (and flooding logs with transient error messages).
> 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.
Yes. Dependency management is a project on its own. I've had my sights on
it for quite a while, but I want to do things right, not as a quick and
dirty hack; that's part of my plan for 2015. And in any case, dependency
management, as a part of general machine state management, should not be
integrated into a process supervision suite, but be built *on top* of it;
that is why I have added notification hooks to s6 (and more hooks are
needed, so the next release will have more).
> The inclusion of state tracking in C is probably best discussed
> in a separate thread.
C or otherwise - there is no reason at all for the supervisors to
perform state tracking themselves. It is a different job, so a
different tool must be created. But please, yes, let's talk about
it.
--
Laurent
Received on Sat Oct 04 2014 - 18:13:43 UTC