In daemontools, a "main" service could optionally have a similar "log" service associated with it, the output of the one fed into the input of the other. Successors to daemontools, such as daemontools-encore and runit, have proceeded in the direction of hardwiring a 1:1 relationship between a "main" service and a "log" service, to the extent of making the utility commands non-orthogonal for "log" services. This package takes the opposite tack.
The service manager supports a flexible logging mechanism, where services can be plumbed together. For every loaded service it creates a pipe, attaching the read end of the pipe to the service process's standard input. Other services can be plumbed to that service. The service manager attaches their standard outputs and standard errors to the write end of the pipe.
This mechanism does not hardwire in a difference between "log" and "main" services.
All services are on an equal footing as far as the service manager itself is concerned.
The client that instructs the service manager, service-dt-scanner or system-control, determines exactly how services are plumbed together.
service-dt-scanner for compatibility maintains the daemontools notion of a set of "main" services each of which may optionally have 1 dedicated "log" service, and plumbs the two together.
system-control makes no such distinction, and simply follows the "log" symbolic link in each bundle directory.
In theory one could set up lengthy pipelines of services, each with its standard output and standard error plumbed to the standard input of the next.
In practice there are two common scenarios.
one logging service for each logged service: This scenario is the same as on the old daemontools, daemontools-encore, and runit systems. This scenario is exemplified by most of the "regular" services that are bundled with the package. The "qmail-smtp-relay" service, for example, is plumbed to a "cyclog@qmail-smtp-relay" logging service.
multiple services all fan-in to a single logging service: This scenario is exemplified by most of the "sysinit" services that are bundled with the package. They are all plumbed to a single "sysinit-log" logging service. This scenario has the disadvantage that the log outputs of multiple parallel concurrent service dæmons are mashed together into a single log. Were these permanently running dæmon processes all emitting log output all of the time, this would cause a mess. But the "sysinit" services that are plumbed to "sysinit-log" are single-shot services that in fact do their work before becoming ready, and have heavy ordering dependencies upon one another. They have one period of activity, and it usually doesn't overlap the activities of the other services.
There is also logging for the system-wide service manager itself.
The system manager starts a logging dæmon, an instance of cyclog, whose standard input is connected to the read end of a pipe, the write end of which is connected to the standard output/error of the system-wide service manager process.
If a service is not plumbed to another service, then it inherits its standard output and standard error from the service manager, and its log output goes to that logging dæmon.
However, that logging dæmon logs to a temporary filesystem (the log files being written to /run/system-manager/log) and has an intentionally small cap on the log file sizes.
It is not suitable for general-purpose logging, and is intended to log just the output of the service manager itself, and perhaps the (fairly humdrum) outputs of cyclog logging dæmons.
All other dæmons should, properly, be plumbed to a logging service.
Per-user managers similarly set up an instance of cyclog, whose standard input is connected to the read end of a pipe, the write end of which is connected to the standard output/error of the per-user service manager process.
The same considerations of inherited standard output and error in spawned per-user services apply; with the per-user log files written to /run/user/$USER/per-user-manager/log.