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.


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