# Compatible old-style startup

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.

## Old-style startup under Mewburn `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:

1. 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`.

2. Mewburn/OpenRC/OpenBSD `rc` activates the `service-manager-svscan` script, spawning `service-dt-scanner /service/`.

   1. `service-dt-scanner` scans `/service/` and for every service found it sends a LOAD command to the `/run/service-manager/control` socket.

   2. `service-manager` loads and manages the services that `service-dt-scanner` tells it to.

3. Mewburn/OpenRC/OpenBSD `rc` activates the `system-control-normal` script, spawning `system-control start normal`.

   1. `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.)

   2. `service-manager` loads and manages the services that `system-control start` tells it to.

## Old-style startup under systemd

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:

1. systemd, monitoring the `/service/` directory as a result of activating the path unit, sees that the directory is non-empty.

2. systemd activates the `service-manager-svscan.service` service, running `service-dt-scanner /service/`.

3. `service-dt-scanner` scans `/service/` and for every service found it sends a LOAD command to the `/run/service-manager/control` socket.

4. systemd, monitoring the `/run/service-manager/control` socket as a result of activating the socket unit, sees that requests have arrived on the socket.

5. systemd activates the `service-manager.service` service, running `service-manager` with an open file descriptor for the control socket.

6. `service-manager` loads and manages the services that `service-dt-scanner` tells it to.

7. systemd activates the `system-control-normal.service` service, spawning `system-control start normal`.

   1. `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.)

   2. `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.