1 2 3 4 next »

1. Systemd tools
2. Unit files and targets
3. Dependencies
4. Fixing problems

Booting up: Tools and tips for systemd, a Linux init tool

by Lennart Poettering, Kay Sievers, Thorsten Leemhuis

These days, Fedora, openSUSE, Mandriva and a few other distributions use the systemd init tool for system starts. It includes its own tools for configuration and diagnosis, and the tricks it needs when the system doesn't start are different from sysvinit's.

The following article about systemd was first published in the German magazine c't 13/11 and has been updated in various places before appearing in The H Open. An article from the same issue of c't on systemd's ideas, approach and functionality was also recently published on The H Open.

The systemd init tool, just over two years old, is already the default in some distributions; a few more include it as an alternative to upstart and the outdated sysvinit. Thanks to compatibility features, some of the commands and tricks familiar from distributions with sysvinit and upstart work with systemd too. To really take advantage of the much newer init system's capabilities, however, administrators should get to know systemd's tools and parameters as well.

The main tool for interacting with systemd is systemctl, a command-line program. The tool requires root privileges to make changes to the configuration or to restart background services, but even non-root users can use some diagnostic requests. If you launch the program without any parameters, you will see a list of the "units" that execute tasks when the system is started, including mounting and checking disks, starting background services and configuring hardware.

For a standard Fedora 15 installation, systemctl lists around 160 active units, divided into ten types. Service units are one of the most important types of units as they take care of background services, which a sysvinit distribution typically starts using init scripts. Mount and automount units mount filesystems. Socket units create sockets and, as soon as a socket is accessed, indirectly start another unit using dependencies. You can use a parameter to tell systemctl to only list certain types of unit, for example all service units:

systemctl --type=service

Systemctl automatically forwards its task to less; you can use the arrow keys to scroll not just up and down but also to the right, since more information is occasionally "hidden" there.

To boot a system, systemd uses units, which are divided into types that systemctl can list separately The first column in the list tells you the name of the unit; the second column, whether systemd was able to load the unit definition. The third column says whether the unit is active. If you include the -a parameter, the program only displays inactive units – that is, units that are installed but not used during boot-up; the same applies to unit files that the init system wasn't able to load, most likely because of an error in the unit file.

The fourth column gives the current status: "exited" means that the process completed without any errors. This is the case for, say, services that don't continue in the background after they've been launched – for example, the service unit that, for compatibility reasons, executes the /etc/rc.d/rc.local file, familiar from sysvinit, at system start. "Running" is for services that are running in the background, such as cron, dbus, sshd and udev.

The sixth column describes the unit. Units labelled "LSB" or "SYSV" have been automatically created by systemd to take care of traditional init scripts.

Services that could not be started or that crashed later are marked as "failed" in the fifth column, in red, if the console can display colours. You can find out when the crash happened and which error code the program provided when it ended using commands such as:

systemctl status ntpd.service

Systemctl's status command provides a time and error code for crashed services For a newly installed Fedora 15, systemctl lists about 60 service units, including the login processes for the text consoles (agetty), since – unlike sysvinit – systemd uses service units to manage these like a normal background service.

Next: Unit files and targets

1 2 3 4 next »