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.
"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.
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.