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.
restart programs are all fairly straightforward and self-explanatory.
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
run program runs the
This utility performs boot-time actions that set up the
/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
This is because "sysinit" services are part of, or precede, bringing up local filesystems; loaded in parallel with (or even before) mounting
/var and re-mounting
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
So it is very important to minimize the amount of output generated by sysinit services.