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
Received on Thu Feb 25 2016 - 19:12:29 UTC