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 nosh 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
service directories.
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.
🔗 Supervisor Translator
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 nosh and 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
systemd uses 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 nosh’s move-to-control-group and unshare to
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
containers (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.
(The following includes affiliate links.)
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
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
If you're interested in being notified when new posts are published, you can subscribe here; you'll get an email once a week at the most.