In association with heise online


The various tasks when booting the system – creating sockets, configuring hardware, mounting storage devices, starting background services – are organised in "units". Every task that systemd performs requires a configuration file for the appropriate unit which only needs to contain the information that is required for this unit – in a mount unit, for example, it contains the storage medium's device file and the target directory. Such configuration files are significantly shorter than traditional init scripts. Their syntax is similar to that of Windows ini files.

Systemd recognises the unit type by the unit's file name. Files that end in .service create service units; they handle services that SysV-init-based distributions will typically start or end using init scripts. Units for mounting and unmounting filesystems end in .mount; the suffix will be .automount if the automounter, a component which automatically mounts filesystems in response to access operations, is involved. Units that end in .path allow systemd to monitor the files and directories that are specified in the unit file via inotify; when an access happens in that path, systemd will start the appropriate unit.

Unit files that end in .socket create one or more sockets for socket activation. However, they don't actually start the related services; this will be done by a service unit that is associated with the socket unit. When a connection request is received, systemd starts the service that is defined there, submitting the open sockets – in a similar way to what Unix/Linux veterans know from inetd.

Zoom Service units handle background services
The unit files that are associated with systemd and the services are located in the /lib/systemd/system/ directory; if an identically named file exists in /etc/systemd/system/, systemd will ignore the one in the lib directory. This allows administrators to copy and customise a systemd unit file without running the risk that it could be overwritten during the next update – this can happen in SysVinit distributions if one of the init scripts stored in /etc/rc.d/init.d/ has been modified.

Systemd dynamically generates certain units itself; as a result, these units don't show up in the filesystem, but they do appear in the unit list that can be retrieved via systemctl. For example, a device unit is automatically generated together with udev for certain devices (such as storage media, PCI devices and TTYs) that are marked as TAG+="systemd" in the udev rules. Similar to the socket and service unit combo, other units can also depend on these device units and start automatically when devices that require them are connected. This system is also used for the .swap units that are automatically generated using the information in /etc/fstab to configure swap space as soon as the specified swap volume appears. Systemd also generates automatic mount units for various other storage devices that are listed in /etc/fstab; therefore, the systemctl list contains more mount units than there are mount unit files.


Files that end in .target define groups of units. They achieve little themselves and serve to call other units that are responsible for services, filesystems or other components. These functions allow boot targets to be defined that are equivalent to the classical SysV runlevels. For example, the unit starts all those services that older versions of Fedora and openSUSE would call in runlevel 3 – in other words, it fully starts the system, but without launching a graphical login manager. The latter appears with the unit, making this unit the equivalent of runlevel 5 and the typical default target.

Zoom Target units start other units via dependencies and can be compared to Sys-V runlevels
When the system is booted, systemd activates a special target unit. Typically, is only used as an alias for different targets such as or Targets can also build or depend on each other; for example, will wait for to start before it launches the graphical user interface.

Where necessary, the addition of "wants" to the unit files allows users to manually define dependencies between units. This can be relevant for services such as the Apache web server, which expects a fully configured network environment when it is started. These services should depend on the However, services such as Avahi or Bind don't require the dependency because they can correctly handle network interfaces that appear or disappear at runtime.

Next: Compatibility and grouping

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