This service is failing to start properly; investigate its log and check its run script.
The service-control command causes the service manager to send signals to the service process(es).
Those processes include the ones that run in the "starting", "failed", and "stopping" states — namely the start, restart, and stop programs and anything that they in their turn run.
So just terminate the process(es) with service-control --terminate.
Bear in mind that some "sysinit" services do things in their start programs that may take a long time.
The "fsck@" service fscks a volume in its "starting" state, for example.
These long-running initialization actions are not necessarily stuck just because they take a long time.
Troubleshoot this by:
… looking at the logs, if possible.
The system manager's own log output can be seen in /run/system-manager/log/.
… watching the bootstrap process interactively. Start the system in rescue mode, then bring up the "normal" target interactively with:
system-control start --verbose normal
Watch for things that are "BLOCKED" and note how far through the boot process system-control gets.
system-control experiences a conflict
The most common conflict is one between kernel virtual terminals and user-mode virtual terminals — the ttylogin@ttyv1 service conflicting with the console-fb-realizer@head0 service.
This is hard, but not impossible, to cause.
Simply disable the one or the other service.
The mount@ services that mount volumes are not enabled in the base service bundles package.
Specifically, if you have your /usr and /var filesystems on separate volumes and you haven't enabled the mount@-usr and mount@-var services then many other services will fail not only to start but even to be found by the "normal" target when system-control goes looking for its dependencies.
You must enable these services.
This can be done explicitly, or by the autoconfiguration system of redo scripts, which will create and enable mount services based upon the contents of /etc/fstab.
In this scenario service A specifies that it is to be started after service B (or service B has specified that it is to start before service A), one or both services are directly or indirectly wanted by the "normal" target, and service B has failed to start.
Look at service B's own logs, and the output of
system-control status B
The most common cause of this is that you have an enabled service whose supervise directory is on a read-only filesystem.
The service manager is thus unable to create/update the control/status API files in that directory.
Notice that "sysinit" services locate their supervise directories under /run/service-bundles/early-supervise/ for this very reason.
The point where they are loaded by the service manager is well before the point that the /var or / volumes are mounted read-write.
/etc/fstab entry is ignored.
The conversion utility ignores entries that are not marked as rw, rq, ro, or sw.
Ensure that the entry is marked with a correct mount type.