Systemd – Replacing init

systemd, init – A new System and Service Manager

On all Linux variants, the software acting as PID 1 was the venerable sysvinit package, though it
had been showing its age for quite a while. Many replacements have been suggested, only one of
them really took off: Upstart, which has by now found its way into all major distributions.

About ( PID 1 ) init
The primary responsibility of an init system is to the central responsibility of an init system
is to bring up and maintaining userspace services. But the traditional SysV init system isn’t fast
enough to bring them up. This is because most of the times init will have to start various services
which prevents it from booting fast. For any fast init system, the following things are crucial.

i) Start less services or preventing services from being started unless required.
ii) Start more services in parallel so that CPU/Memory/IO are used efficiently, there by reducing the overall start up time.

Most of the current init systems that try to parallelize boot up still synchronize the start-up of the various daemons involved which slows down the boot up. A good init system is capable of dynamically adjusting to services and needs to listen to both hardware and software changes. This kind of start-up synchronization results in the serialization of a significant part of the boot process. traditional Unix daemons wait until the socket the other daemon offers its services on is ready for connections. Usually that is an AF_UNIX socket in the file-system. This again slows down the boot up process.

So, in short there are many disadvantages of the traditional sysvinit or init process. In order to overcome these issues and have an efficient and ideal init system, systemd was introduced ( though in experimental stages ). systemd starts up and supervises the entire system. It is a system and service manager for Linux operating systems. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services. When run as system instance, systemd interprets the configuration file system.conf, otherwise user.conf

systemd provides a dependency system between various entities called “units”. Units encapsulate various objects that are relevant for system boot-up and maintenance. The majority of units are configured in unit configuration files, however some are created automatically from other configuration or dynamically from system state. Units may be ‘active’ (meaning started, bound, plugged in, … depending on the unit type, see below), or ‘inactive’ (meaning stopped, unbound, unplugged, …), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called ‘activating’, ‘deactivating’). A special ‘failed’ state is available as well which is very similar to ‘inactive’ and is entered when the service failed in some way (process returned error code on exit, or crashed, or an operation timed out). If this state is entered the cause will be logged, for later reference. Note that the various unit types may have a number of additional substates, which are mapped to the five generalized unit states described here.

The following unit types are available:

1. Service units, which control daemons and the processes, daemons that can be started, stopped, restarted, reloaded.
2. Socket units, which encapsulate local IPC or network sockets in the system, useful for socket-based activation.
3. Target units are useful to group units, or provide well-known synchronization points during boot-up. This unit type is used for logical grouping of units: instead of actually doing anything by itself it simply references other units, which thereby can be controlled together.
4. Device units expose kernel devices in systemd and may be used to implement devicebased activation.
5. Mount units control/encapsulates mount points in the file system. systemd monitors all mount points how they should be attached or detached from mount-points
6. Automount units provide automount capabilities, for on-demand mounting of file systems as well as parallelized boot-up. This unit encapsulates an automount point in the file system hierarchy. Each automount unit has a matching mount unit, which is started (i.e. mounted) as soon as the automount directory is accessed.
7. Snapshot units can be used to temporarily save the state of the set of systemd units, which later may be restored by activating the saved snapshot unit. Similar to the target units snapshots do not actually do anything themselves and their only purpose is to reference other units. These units can be used to save/rollback the state of all the services and units of the init system.
8. Timer units are useful for triggering activation of other units based on timers.
9. Swap units are very similar to mount units and encapsulate memory swap partitions or files of the operating system.
10. Path units may be used to activate other services when file system objects change or are modified.

Units are named as their configuration files. Some units have special semantics. All these units can have dependencies between each other. As soon as a device becomes available a certain service is started. Mounts get an implicit dependency on the device they are mounted from. Mounts also gets implicit dependencies to mounts that are their prefixes (i.e. a mount /home/lennart implicitly gets a dependency added to the mount for /home) and so on.

systemd knows various kinds of dependencies, including positive and negative requirement dependencies. If only a requirement dependency exists between two units, but no ordering dependency and both are requested to start, they will be started in parallel. It is a common pattern that both requirement and ordering dependencies are placed between two units. Also note that the majority of dependencies are implicitly created and maintained by systemd. In most cases it should be unnecessary to declare additional dependencies manually, however it is possible to do this.
Application programs and units (via dependencies) may request state changes of units. In systemd, these requests are encapsulated as ‘jobs’ and maintained in a job queue. Jobs may succeed or can fail, their execution is ordered based on the ordering dependencies of the units they have been scheduled for. On boot, systemd activates the target unit whose job is to activate on-boot services and other on-boot units by pulling them in via dependencies.
Processes systemd spawns are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy. systemd uses this to effectively keep track of processes. Control group information is maintained in the kernel, and is accessible via the file system hierarchy (beneath /sys/fs/cgroup/systemd/), or in tools such as ps(1) (ps xawf -eo pid,user,cgroup,args is particularly useful to list all processes and the systemd units they belong to.).

Systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the host name or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys or /proc.

So, In short, systemd is compatible with the SysV init system to a large degree: SysV init scripts are supported and simply read as an alternative (though limited) configuration file format. The SysV /dev/initctl interface is provided, and compatibility implementations of the various SysV client tools are available. Systemd though it, is in the expermental stages is fast and efficient to effectively manage various services on a Linux distro.

References: man systemd

Leave a Reply