In association with heise online

Stopped at the starting line

If there are problems during boot-up that systemd seems to be directly or indirectly involved in, start the kernel with the following parameters:

systemd.log_target=kmsg systemd.log_level=debug

Systemd recognises the parameters and provides extensive troubleshooting information on the console. At the same time, the information is saved for later analysis in the kernel notification buffer created by dmesg.

Zoom The "systemd-cgls" tool can display the control groups and the processes belonging to them
The command line programs poweroff, halt and reboot are part of systemd, but the system can also be shut down or restarted using systemctl commands, which are the same. The system can also be restarted this way:

systemctl kexec

After all services have been stopped, systemd tells the running kernel to directly start a previously configured Linux kernel, which allows for fast restarts, since it bypasses BIOS and boot-loader. If no kexec kernel is configured, systemd executes a normal restart.

Deep down

For standard administration tasks, you will usually only come into contact with service and target units; the others are primarily important for deeper systemd functions or, during boot-up, take care of everything that distribution-specific scripts took care of in sysvinit and upstart distributions. These tasks include mounting the filesystems specified in /etc/fstab, activating the swap space and occasionally cleaning up directories for temporary files.

For some of these tasks, systemd has an automount function that can create pseudo mount points for filesystems configured in /etc/fstab; they are not really mounted until they are first accessed. Adding comment=systemd.automount in /etc/fstab changes any mount point into an automount point, which can speed up the boot-up process and be interesting for access to network shares, since the WLAN connection is not created until the user uses NetworkManager.

Looking for answers

Systemctl can be used to tell systemd to send a signal without knowing the service's process ID. For example, the following command puts rsyslogd in debug mode, which is ended when you enter the command a second time.

systemctl kill --signal=USR1 rsyslogd.service

If you don't specify which signal to send, systemctl sends a normal term signal, which ends all processes belonging to a service.

Zoom Systemd includes a program that visualises the boot processes; the dark red areas signal services' start phases
The command systemd-analyze tells you how long the system took to boot and how much of that time was due to the kernel, initramfs and the systemd-controlled configuring of the userland. If you want to look more closely into the latter factor, use systemd-analyze blame to get individual units' start times. For more detailed information on the boot process, the program can create an SVG file that visualises the units' starts:

systemd-analyze plot > plot.svg

Sometimes, this can be used to track down units that excessively prolong boot-up. The seventh part of the "Systemd for Administrators" blog series has a few tips on correctly interpreting these results. The series, with twelve sections at the moment, also includes many other tips and notes on using systemd:

Lennart Poettering's homepage also has many other articles with more background information on the init system. In addition, Poettering recently listed some of the changes made to systemd in the last year and a half in his third "Systemd Status Update".

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit