As an alternative to the full startup and shutdown mechanisms that involve running the system manager, one can use a mechanism that operates more like traditional daemontools.
The service manager still runs, but instead of being sent control messages by system-control it is sent control messages by service-dt-scanner, which implements old-style daemontools service activation involving a /service/ directory.
Of course, one has to do one's own system management, with some program running as process #1 that invokes service-manager and service-dt-scanner.
Exactly what one uses is beyond the scope of this guide, obviously.
rc, OpenRC, and OpenBSD rc
The package comes supplied with some rc.d scripts that enable one to run the service manager and old-style scanner under Mewburn rc (on FreeBSD, NetBSD, and others), under OpenRC, or under OpenBSD rc.
service-manager is a script that runs runs service-manager via local-datagram-socket-listen.
service-manager-svscan is a script that runs service-dt-scanner against the /service/ directory.
service-control-normal is a script that runs system-control with the start normal subcommand.
Under the Mewburn system, all are enabled with the usual _enable variables in /etc/rc.conf.
What happens at system bootstrap, with these enabled, is:
Mewburn/OpenRC/OpenBSD rc activates the service-manager script, spawning service-manager with an open file descriptor (set up by local-datagram-socket-listen) listening on /run/service-manager/control.
Mewburn/OpenRC/OpenBSD rc activates the service-manager-svscan script, spawning service-dt-scanner /service/.
service-dt-scanner scans /service/ and for every service found it sends a LOAD command to the /run/service-manager/control socket.
service-manager loads and manages the services that service-dt-scanner tells it to.
Mewburn/OpenRC/OpenBSD rc activates the system-control-normal script, spawning system-control start normal.
system-control start finds all of the services wanted-by the normal target, sends a LOAD command for every such service to the /run/service-manager/control socket, and sends a START command.
(A special cut-out, only in place when the system is configured to run under Mewburn/OpenRC/OpenBSD rc, prevents the sysinit target and its dependencies from being started, on the grounds that the Mewburn/OpenBSD rc takes care of its equivalent.)
service-manager loads and manages the services that system-control start tells it to.
The package comes supplied with some unit files that enable one to run the service manager and old-style scanner under systemd.
service-manager.socket is a systemd socket unit that defines a local-domain datagram socket named /run/service-manager/control.
service-manager.service is a systemd service unit that defines the socket-activated service associated with that socket.
The service runs service-manager, which understands the
systemd LISTEN_FDS convention
and so can be run as a systemd socket-activated service in this manner.
service-manager-svscan.path is a systemd path unit that tells systemd to watch the /service/ directory.
service-manager-svscan.service is a systemd service unit that defines the path-activated service that is associated with that path.
The service runs service-dt-scanner.
You must enable the path and the socket units if you wish to run the service manager under systemd. What happens at system bootstrap, with these enabled, is:
systemd, monitoring the /service/ directory as a result of activating the path unit, sees that the directory is non-empty.
systemd activates the service-manager-svscan.service service, running service-dt-scanner /service/.
service-dt-scanner scans /service/ and for every service found it sends a LOAD command to the /run/service-manager/control socket.
systemd, monitoring the /run/service-manager/control socket as a result of activating the socket unit, sees that requests have arrived on the socket.
systemd activates the service-manager.service service, running service-manager with an open file descriptor for the control socket.
service-manager loads and manages the services that service-dt-scanner tells it to.
systemd activates the system-control-normal.service service, spawning system-control start normal.
system-control start finds all of the services wanted-by the normal target, sends a LOAD command for every such service to the /run/service-manager/control socket, and sends a START command.
(A special cut-out, only in place when the system is configured to run under systemd, prevents the sysinit target and its dependencies from being started, on the grounds that systemd services and targets take care of its equivalent.)
service-manager loads and manages the services that system-control start tells it to.
At shutdown, systemd first deactivates the system-control-normal.service service, spawning system-control start shutdown to perform a normal orderly shutdown.
This sends various commands to the service manager to attempt, with various signals, to stop all services that the shutdown service has a conflicts/ relationship with.
It happens before systemd attempts to shut down the actual service-manager.service itself.