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 , 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 ) |svscanboot|. This was of course how service management had been done on AIX since 1990 and on AT&T Unix since 1988 . 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| 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| (in its |start| and |stop| subcommands) and |service-dt-scanner| . 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 , too.