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.
In the first scenario there is, as with the old daemontools, daemontools-encore, and runit systems, one logging service for each logged service. 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.
In the second scenario 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 daemons are mashed together into a single log.
Were these permanently running daemon processes all emitting log output all of the time, this would cause a mess.
But the "sysinit" services that are plumbed to "sysinit-log" in fact do most of their work in their startup programs 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 service manager itself.
The system manager starts a logging daemon, 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 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 daemon.
However, that logging daemon 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 daemons.
All other daemons should, properly, be plumbed to a logging service.