Kelly Dean:
> Surely this is a common question.
>
It's a common redesign.
In the original daemontools, |supervise| knows nothing at all about the
difference between "log" and "main" services. Linking up the standard
I/Os with pipes, to connect "main" services to "log" services, and
knowing the directory layout that delineates them, is entirely the
domain of |svscan|, which in its turn knows nothing at all about the
control/status API and about supervision. M. Bercot has stuck with this
design.
As laid out in this Frequently Given Answer
<
http://jdebp.eu/FGA/daemontools-family.html>, three of the other
toolsets did not, and went down the path of tighter integration of the
twain. They baked in a relationship between "main" and "log" services.
In the original daemontools design, it was theoretically possible to run
|supervise| under something else, that set up different relationships.
Indeed, in the original daemontools |svscan| came along (in version
0.60) about two years after |supervise| did, /originally/ in early
versions people were expected to run |supervise| directly, and it was
more like |daemon| in its operation. This was until it became apparent
that "dæmonization" is a fallacy, and simply does not work on modern
operating systems where login sessions have gone through too many
one-way trapdoors for escaping to a dæmon context to be viable. Running
dæmons outwith login session context /right from the top/ became the
way, with |svscan| and (the also since much-replaced
<
http://jdebp.eu./FGA/inittab-is-history.html#svscanboot>)
|svscanboot|. This was of course how service management had been done
on AIX since 1990 and on AT&T Unix since 1988
<
http://jdebp.eu./FGA/unix-service-access-facility.html>.
My nosh toolset did not stick with the original design in this regard,
either. But I did not go for tighter integration, which I thought to be
the wrong thing to do. |service-manager|
<
http://jdebp.eu./Softwares/nosh/guide/commands/service-manager.xml>
manages a whole bunch of services, does all of the waiting and spawning
in a single process, which is conventionally also a subreaper, and
provides all of the control/status APIs. But the knowledge of the
relationships amongst those services, and of directory structures, is
entirely /outwith/ that program.
It is, rather, in programs like |system-control|
<
http://jdebp.eu./Softwares/nosh/guide/commands/system-control.xml> (in
its |start| and |stop| subcommands) and |service-dt-scanner|
<
http://jdebp.eu./Softwares/nosh/guide/commands/service-dt-scanner.xml>.
They decide the policy, which services' standard I/Os are plumbed
together and how a "main" service indicates its "log" service. They
instruct |service-manager| with the |service/| and |supervise/|
directories, passing it open file descriptors for them, and what to
plumb to what, and it just runs the mechanism. They even implement /two
different/ policies, one with ordering and dependency processing and a
full /service bundle/ mechanism and the other more like the old
daemontools and s6 /scan directory/. There is no reason that a third
tool could not implement a third policy still.
There is not even a requirement of a 1:1 relationship between "main" and
"log" services, and indeed the set of pre-supplied service bundles has
fan-in arrangements for a few of the short-lived single-shot services
that run at bootstrap/shutdown, with them sharing a single logger. The
pre-supplied per-user services have three fan-in sets
<
http://jdebp.eu./Softwares/nosh/guide/per-user-user-services.html#logging>,
too.
Received on Sun Feb 03 2019 - 10:39:40 UTC