What is “systemd”


On every Unix system there is one process with the special process identifier 1. It is started by the kernel before all other processes and is the parent process for all those other processes that have nobody else to be child of. This process is responsible for bringing up and maintaining user space during boot. User space is the memory area where all user mode applications and some drivers execute. This is separate from kernel space which is strictly reserved for running privileged kernel, kernel extensions, and most device drivers.

Note: run “pstree” command in your terminal to display a tree of processes running on your system. You will see that the root of all processes is one process called “init”  aka PID1.

Historically on Linux the software acting as PID 1 was the SysVinit package, though it had been showing its age for quite a while. Improvements to the boot process has been something that many distributions have been working on for a few years now and this led to the development of many alternatives. Among them it looks like the one that is gaining more popularity and is being adopted by more and more distributions is “systemd”.

The traditional SysVinit system was not particularly fast, and the main reasons were:

  • it was trying to start too much (all configured services)
  • dependencies between services made concurent (using processing threads) start-up difficult
  • the boot logic was modeled around shell scripts, which are slow in execution and very fragile (change their behavior drastically based on environment variables which makes it hard to oversee and control)

SystemD tries to start at boot time only what is needed, and take care of as many tasks as possible in parallel in order to use resources efficiently, and hence minimize the overall start-up time. It also defers the starting of other services until they are actually needed. For example starting the SSH daemon is not really necessary right after boot, as long as it is then started on the first connection attempt.

Another thing that was done to speed up the boot time was to rewrite in C some of the shell scripts that SysVinit was using, especially the ones that were doing trivial setup and tear-down of services.

Also pre-creation of sockets and file handles for services, allows dependent services to start faster. For example, systemd will hold open the filehandle for /dev/log for syslog, and subsequent services that send to /dev/log will have their messages buffered until syslogd is ready to take over.

A central part of a init system should be process babysitting. it should watch services, control when a daemon starts and restart it if it shuts down .

Setting up a good, minimal, and secure working environment for a daemon is necessary. With systemd, for each process that is spawned, you may control: the environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems.

cgroup membership is securely inherited by child processes. By using cgroups instead of process identifiers (PIDs), the system becomes more secure, because processes that do double-forking will have no chance to escape the supervision of its parent . (You can find the cgroups of a process by reading /proc/$PID/cgroup. cgroups)

Finally logging is an important part of executing services. systemd provides logging to daemons it spawns right from the beginning and can easily connect stdin/stdout/stderr of services to syslog, /dev/kmsg or arbitrary TTYs. If processes crash systemd is able to collect information about them, keep it around for the administrator, and cross-link that information with what is available from crash dump systems and in logging systems or the audit system.

To ease adoption, upstart is backwards-compatible with sysvinit and Upstart, so it can use these systems configuration files.

To run systemd the lower bound on kernel version is set in the ebuild to 2.6.39. systemd uses many new Linux-specific features, and does not limit itself to POSIX, which makes it a tool designed exclusively for the Linux kernel. Lennart Poettering, the software engineer who initially developed systemd, has been known as an advocate to speeding up Linux development at the expense of breaking compatibility with BSD. Because of this strong dependency on Linux tools, Debian developers are reluctant to make systemd the default, since Debian’s non-Linux ports will not work with systemd.

« (Previous Post)