In association with heise online

Traditional parts

For compatibility reasons, systemd can also be used with System-V and LSB init scripts. Such scripts aren't just used for starting and stopping services in Linux distributions with SysVinit; they also work with Upstart. These init scripts are interpreted by a shell and require parameters such as "start", "stop" or "restart"; an approach that has existed since the early days of the System-V init system.

The developers of commercial software typically also include Sys-V and LSB init scripts with their background services. Systemd automatically generates a service unit from them so that it can internally treat them as proper service units; however, the init tool will ignore Sys-V and LSB init scripts if it detects an identically named unit file.

Groups

When starting them, systemd sticks every service into a dedicated control group (cgroup) that is named after the service. Modern kernels support this technology which isolates processes and offers optional controllers to further tweak the allocation of hardware resources.

Child processes inherit the group properties. This allows systemd to manage process groups as coherent units, for example to ensure that all related processes are stopped when a service is shut down. Administrators can also use the normal cgroup interfaces to control the range of resources that is available to a service; manually allocating processes is no longer required.

Broad approach

Systemd includes a range of units that perform various fundamental tasks during system initialisation. Some of them are given the same format as a background service. For example, when required, the fsck-root.service service unit triggers a root filesystem check before a writeable filesystem is mounted by remount-rootfs.service; hwclock-load and hwclock-save adjust the time to that of the system clock. In SysVinit and Upstart distributions, these and dozens of similar tasks were handled by shell scripts such as /etc/rc.sysinit or by a collection of small scripts stored in /etc/rcS.d/*. These scripts are heavily customised for each distribution family and will, therefore, behave very differently in Debian than they do in Fedora or openSUSE; this is the reason why Fedora and RHEL users can set their keyboards in /etc/sysconfig/keyboard but will search in vain for this directory in Debian.

Many systemd units start C programs which are thought to be faster and more robust than the shell scripts that previously performed these tasks. By integrating these services, systemd is trying to eliminate many of the differences between distributions. This makes it easier for developers to do their jobs because they can provide unit files for their services and know what things to expect to be included in systemd. Incorporating Sys-V init scripts is much more difficult because these scripts must accommodate distribution-specific characteristics.

Details

Further background information on the ideas behind systemd, as well as its operation and use, can be found in the systemd man pagessystemd and systemd.conf. Such pages also exist for each of the unit types – for example for systemd.unit or systemd.service. Lennart Poettering's homepage offers links to numerous articles that explain the background of the init system, for instance the "systemd for Developers" series, which currently includes two parts:

In his third "Systemd Status Update", Poettering recently listed some of the new features that have been added to systemd in the past eighteen months.

Print Version | Permalink: http://h-online.com/-1565543
  • 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