Troubleshooting

A service is continually switching between the "running" and "failed" states, and shows an uptime of 0 seconds (or 1 second).

This service is failing to start properly; investigate its log and check its run script.

A service is stuck in the "starting", "failed", or "stopping" states.

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.

The system bootstrap never fully completes.

Troubleshoot this by:

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-kvt-realizer@ttyv1 service. This is hard, but not impossible, to cause. Simply disable the one or the other service.

Volumes are not mounted, and services needing those volumes to be mounted cannot start

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.

Services remain blocked

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 service manager reports errors when attempting to load a service

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.

fsck ran and then nothing else started

The initial non-interactive fsck of mounted filesystems usually runs in "preen mode", which proceeds relatively quickly. If, however filesystem tunable options cause a full fsck to run, system-control can sometimes time out waiting for the filesystem check services to finish. This is because there's a time limit to how long system-control will attempt to bring the system up.

The limit is there so that a system that fails to fully come up can be brought down. Without the time limit, the on-going attempts to bring the system up would defeat the process of trying to bring the system down, if an administrator chose to reboot. And this is the remedial action to take here, in fact. Simply reboot the system after all fscks have successfully run, and the monitor-fsck-progress service has removed its user interface.

An /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.

The conversion utility uses the conventional C library functions getfsent() et al. to parse the /etc/fstab file. It does not use its own private custom parser. These C library functions do not behave as do the custom parsers in some other utilities.

In particular, note that getfsent() does not determine the sw status from the filesystem type field as some custom parsers do. The BSDs explicitly require, as stated in their /etc/fstab manuals, that swap entries be marked as sw. The same requirement actually exists in the GNU C library, but its manual does not mention this and some custom parsers deviate from the behaviour of the GNU C library and thereby make it erroneously appear that this is not necessary.

GNOME Terminal refuses to start.

The GNOME Terminal command does little more than send its environment and arguments via the Desktop Bus to the org.GNOME.Terminal service. Unfortunately, this service is excessively fussy and easy to break.