Hi all, I find http://skarnet.org/software/s6-rc/why.html too dependent on phrases that aren't well enough defined, and phrases that are too similar.
For the purpose of *this one email thread* I'm going to define a "Process Grand Supervisor" as a grand process that runs a bunch of "Process Supervisors", that in turn run, rerun, turn on and turn off, and output status of the processes they supervise. In other words: Process Grand Supervisor | `Process Supervisor (many) | `Process (1, or 2 if there's a ./log) The Process Grand Supervisor runs the Process Supervisors in parallel, with ordering completely undefined. A "Supervision Suite" should be defined as all the software to implement, run and control both the Process Grand Supervisor and the Process Supervisors. Extreme care should be taken never to use "Supervision Suite" in place of Process Grand Supervisor. In the Runit world, Process Grand Supervisor=runsvdir, while Supervision Suite refers to the entire Runit package. These definitions need to be used consistently. A "Process Ordering Facility" (for the purposes of this one email thread) is software that can be added to a Process Grand Supervisor for the purpose of defining which order Process Supervisors are run. The Process Ordering Facility can take many forms, three of which are: * Shellscripts that run before the Process Supervision Suite is started (like Runit's 1 and 2 files) * Manipulation of down files (like LittKitt) * Another kind of addition, added to an existing Process Supervision From what I understand, a Process Ordering Facility is a small part added to a Process Grand Supervisor. It does not contain a Process Grand Supervisor, nor is it a form of Process Grand Supervisor (has-a relationship). It's something you bolt on to a Process Grand Supervisor. Continuing on definitions, I think things that run should be called either "processes" or "daemons" or "services", but only one of those words should be used throughout, and no attempt should be made to draw any distinction between any of the three. Already, people on all sorts of communication venues use these words interchangeably, and then others try to appoint some sort of arbitrary distinction, and the whole thing is a swamp of misunderstanding. Personally, I'd vote for "process" as the one and only word, but an argument could be made that the Process Supervisor and Process Grand Supervisor are also processes, so the thing supervised by the Process Supervisor should be called the "service." Personally, I see no reason to ever use the word "daemon". For the rest of this email I'll use "service" for the thing run by the Process Supervisor... There are two kinds of services: * Oneshot services * Long-run services These phrases are crystal clear and have been used forever in this community. One could also make the point that there could be foreground services: I'll worry about that later. There are other definitions that need to be clarified and consistently agreed upon: init system (there's a special place in hell for the fool who says "init" when he means sysvinit), PID1, "daemonizing" for those fools who think backgrounding should be evidence of readyness, and probably others. I leave that for another time. WHY THIS MATTERS A lot of people have gone to a lot of trouble to make excellent Supervision Suites and init systems that use Process Supervision Suites. This fact assumes new importance as more people get sidetracked, misled, or dragged kicking and screaming to systemd: http://skarnet.org/software/s6/systemd.html The trouble is this: Nothing in any existing Process Supervision Suite docs of which I'm aware showcase the robust and simple architecture bestowed by Process Supervision Suites and the init systems they [help] facilitate, unless the reader has quite a bit of familiarity with the situation, and the discipline to read *a lot*. Which is bad news, because most people who could benefit from an init featuring a Process Supervision Suite are a lot more like me than they are most of you. If they're lucky, their knowledge of Process Supervision Suites is "Yeah, daemontools is that thing you have to install to get djbdns to run." If they're unlucky, they ask "What's a Process Supervision Suite? What's daemontools?" When confronted with today's Process Supervision Suite documentation, their eyes would quickly blur with all the undefined concepts, the similarly worded undefined concepts, and the lack of diagrams or other explanation of relationships. And they'd figure "Hey, systemd works OK, I'll stay where I am." And then the Redhat/Freedesktop contingent would get even more power to consumer more of the Linux low level programming, to the point where using a Process Supervision Suite would preclude a system most people want to have. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key