Supervisors and Init Systems: Part 7
This post is the seventh in my series about supervisors and I’m discussing some ideas that I’ve had while writing this series.
While I’ve written this series I’ve had a few ideas that I think would improve the usage of the supervisors I prefer and also make life easier for those who don’t really care. The first, is of the latter variety:
Inside-out supervisord wrapper
supervisord has some great features that clearly make it attractive to
most developers. Instead of using it and being forced to reimplement the low
level guts of a supervisor in Python, why not use an existing supervisor (maybe
runit if you wanted to keep it simple, or
s6 if you wanted something advanced) and then just expose the features
you want (the web interface, the XML-RPC, etc) as tooling on top? Similarly,
the INI style configuration could be compiled to
runit (or whatever) style
I don’t think this would be a huge amount of work and it would reduce (I think)
overall code and I suspect it would be more reliable since
runit has been
around forever and is totally battle tested.
nosh already does this for
systemd units, but I think it would be
worth to consider going further. I think
systemd units being the interchange
format would be perfectly reasonable, but being able to render simple ones into
runit and more complex ones into
s6 would be a great end game to
me. Similarly the tool could ship with a
supervisord parser that would allow
easy migration if you wanted.
And unlike the
nosh version, since this is an offline tool it can be written
simply with Perl or some other friendly language, instead of C or C++. At the
very least this might make it simpler for people to help.
Better container support
cgroups out of the box to support constraining the resources of
user sessions, services, etc. This is useful, and
nosh provides similar
utility though at what feels like a pretty low level.
cgroups are only half
of what we call “containers” though. A couple of years ago I blogged about
unshare, which takes care of the other half
of the equation: namespaces. Namespaces allow you to more accurately constrain
(or contain) your services, such that if you terminate a service, all of it’s
children go away as well.
While this can be done with process groups and sessions, if the service writer is sufficiently determined (or just as likely: confused) they can situate their processes such that some will end up outside of the process group or session or whatever.
While I could use
achieve a semblance of containers, I have a feeling that there may be a better
option. On the other hand, I do suspect that the underlying Linux features of
cgroups and namespaces, respectively) just are too weird to be
cleanly made into pretty chain-loading tools. This is not the first time I’ve
felt this way.
If anyone wants to get started on a project to do one of the above ideas, let me know. I am happy to promote or pitch in or help in any other way. I doubt I’ll have a chance to work on any of these things, but I think all of them (well maybe not the last one) are worth doing.
This topic is very unix heavy, so if you are totally lost or would like an in depth refresher, Advanced Programming in the UNIX Environment, by Stevens is a good option.
Similarly, some of the tools above (and many more in later posts) discuss tools that while written for assistance in supervision are useful in isolation. I think that The Unix Programming Environment does a great job diving into tools that are general enough to stand on their own.Posted Wed, Aug 2, 2017