Supervisors and Init Systems: Part 5
This post is the fifth in my series about supervisors. The first two posts were about traditional supervisors. The third was about some more unusual options. The fourth was about the current most popular choices. This post is about some of the unusual trends I’ve noticed during my three year long obsession with supervisors.
There are some kinds of software that most programmers seem compelled, fated, or doomed to reinvent or even simply reimplement: templating systems, web frameworks, and to a lesser extent ORMs. Supervisors are firmly not in this category.
The engineers and artists who build these things have tendencies that single them out from the rest of us. Much of this may simply be the legacy of djb. Ultimately it doesn’t matter, but I find it interesting to see these weird corners of Unix systems that most people take for granted or don’t even know about.
🔗 Accurate and In-Depth Documentatoin
Most documentation I interact with on a daily basis is reference. Often it lacks examples, any instruction or guidance, or details regarding resource usage or time complexity. Instead documentation tends to provide just enough to use the library or tool in question.
Contrast this with typical documentation of these supervisors. Here are just a few bits of documentation for some of the supervisors discussed here:
These are all a wealth of helpful and (to me) interesting information.
🔗 Attention to Detail
A lot of what I do in my day to day work is try to think of ways that I can ensure that, even when engineers don’t think about all the ways they could make mistakes, the system will keep working when Murphy strikes. I do not blame most engineers for not being intimately familiar with all of the various details of the computer, but I could list a dozen incredibly important details that most engineers forget about or don’t even know.
Contrast this with the typical implementor of a supervisor. Here are a couple documentation snippets that I think show this:
s6-svscan does not use malloc(). That means it will never leak memory. However, s6-svscan uses opendir(), and most opendir() implementations internally use heap memory - so unfortunately, it’s impossible to guarantee that s6-svscan does not use heap memory at all.
[daemonproxy supports] command-line options to allocate a fixed number of objects of a fixed size at startup, so it never needs to call malloc again
(from the daemonproxy readme).
While this is simply about malloc, there are many other examples if you look.
🔗 Portability
Ignoring systemd, many supervisors make efforts to work on a wide variety of
Unix systems. nosh, for example, was written expressly with FreeBSD in mind
because all other major SysV replacements have either been too weird (launchd)
or Linux specific (systemd.) So the author made nosh. Most other supervisors
stick to POSIX standards so that they can run on most Unixes.
I really wanted to write more about this. I had a whole section I cut out about alternate libc implementations. I had to stop because I have a cold that I’ve gotten due to lack of sleep (due to children who are sick.) Anyway, I expect to write one more post, maybe two if I can pull it off. The next one will either be about the ideas that writing these posts inspired, or about readiness protocols.
(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.