# Anatomy of a sysinit service

Various pre-packaged services are "sysinit" services, started as a result of being wanted by the "sysinit" target (either directly or indirectly via a targets such as "local-fs").

The machine-id service in the sysinit services collection is an example of a sysinit service. Its `start`, `stop`, and `restart` programs are all fairly straightforward and self-explanatory. And its `ready_after_exit` flag file causes the service to be considered ready only when its `run` program has exited. This is because the service is a "single-shot" service, considered "ready" when its `run` program has done its work.

>     #!/bin/nosh
>     #Set up the machine ID
>     move-to-control-group ../machine-id.service
>     envdir env
>     setup-machine-id

The `run` program runs the `setup-machine-id` utility. This utility performs boot-time actions that set up the `/etc/machine-id` and `/run/machine-id` files amongst others.

Most "sysinit" services are single-shot services that do their work and then exit. Only a few, such as the log services and the plug and play manager service, have long-lived dæmon processes.

## location

"sysinit" services live in `/etc/service-bundles/services`. This is because "sysinit" services are part of, or precede, bringing up local filesystems; loaded in parallel with (or even before) mounting `/usr` and `/var` and re-mounting `/` read-write.

For the same reasons, the supervise directories for "sysinit" services live under `/run` (more specifically usually `/run/service-bundles/early-supervise`), because they must be writable before the filesystem containing `/etc` is remounted read-write. The service manager is told to load them, and thus needs to create their control/status API files, first thing in the bootstrap procedure.

## logging

With the exception of the plug and play manager service, sysinit services all use a fan-in model of log service plumbing. The plug and play manager is a long-running service and has its own dedicated log service. Most other sysinit services are single-shot services that do not have long-running processes, and their log outputs all fan-in to a single "sysinit-log" logging service.

The logging services have to come up after the filesystem containing `/var/log` is available and writable. Log data from the logged services sits in its input pipe until then. The consequence of this is that too much log output from sysinit services has the potential to deadlock the system. (Too much output from the plug and play manager service simply halts it until its log service comes up. The plug and play manager usually isn't in the critical path for mounting `/var/log` read-write.)

So it is very important to minimize the amount of output generated by sysinit services.