svscan and supervise

[Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>]

[-- Attachment #1: Type: text/plain, Size: 3626 bytes --]

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.