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
