Introduction

[ Note: The Rehat Manuals have greatly improved with Redhat7. At the time of this writing, information on systemd is in the System Administration Manual Chapter 6. ]

We have seen in the previous sections how traditional System 5 initialization proceeds using the initialization scripts. It has probably occurred to you that, although they make the initialization process easy to customize, basing it on shell scripts seems a bit klunky. This is true. Even more important, the initialization process is slow. There are two reasons for this slowness: the use of shell scripts, which are slow, and the limited ability to encode dependencies using a single integer (in the init script 'start/stop order'), which means the initialization proceeds sequentially - one subsystem after another - even though much of it could proceed in parallel. (Note: what system 5 init called subsystems are referred to as services in systemd, and we will use that term from now on.)

An attempt was made in RedHat 6 (ala Ubuntu) to improve this mechanism using upstart. upstart allowed the administrator to encode dependencies explicitly in each job individually. That is an improvement, but encoding dependencies can be tricky, and the event-driven mechanism used in upstart was found to be cranky. This meant that moving services to upstart jobs was a tedious and error-prone task.

Besides these issues, there have always been some problems with init's ability to be overall guardian of the system. This is because of two reasons. First, it is only responsible for part of what is going on on the system - tasks that are started directly by it. Many parts of the system (such as filesystems and devices) are outside of its purview.  Second, init does not have full control of the services it starts. One example of this, which occurs frequently, is a process that it starts on behalf of a service, which starts other processes. If the service needs to be restarted, these children of init's children can be difficult to round up.

These problems were insurmountable when the original init was created. Since then, however, capabilities have been added to linux that enable a master init program to have better control of all of the system and to isolate and maintain control of services more completely. This facilitated the move of some other parts of linux into systemd to give it control over such objects as devices and filesystems. systemd can perform mounts, automounts, and create and remove devices as needed by the services it starts.

Many of these issues were goals of upstart - and it was a major step in this direction. The design of systemd takes these advancements one step further to simplify the dependency issues and give it more complete control of the services' environments. This is done using some of those newer capabilities of linux and a few novel approaches. Here are some examples:

• systemd uses control groups to maintain the services it manages. Each process it starts is placed in its own control group. Then if that process starts other processes, they are in the same control group. Being in a single control group makes it impossible to lose track of a process that is started on behalf of the service. (A control group in systemd is called a slice.)

• placing its processes in control groups also allows systemd to manage their resources effectively, since limitations can be placed on the control group that  processes in the control group cannot escape.

• use of the kernel's ability to block a process when its resource is unavailable is made use of to simplify dependency resolution and overlap filesystem mounting and checking operations. The most significant example of this is by blocking on daemon communication attempts. Most daemons (remember, services are usually daemons) communicate either via their own socket or dbus' socket. Since systemd has control of devices and filesystem objects, it can create the sockets early and hand them off to the service. Then if a second service tries to communicate with the daemon before it is ready to read the socket, the second service is simply blocked until the daemon is ready. This also allows less-often-used services to be lazy-loaded, meaning the service does not have to be started until someone tries to communicate with it - so long as the socket exists! This means that the dependency does not even need to be encoded, thus simplifying the dependency specification!
  

systemd responsibilities and compatibility

systemd can take over responsibilities that are traditionally the purview of other services, but it can coexist with existing services as well. In particular, systemd can perform logging and run processes periodically like crond. We will see an example of this second capability later.

interacting with systemd

systemd is complex. Fortunately, it is not conceptually complex - there's just a lot of it. To simplify this, we are going to take a trip through systemd depth first - looking at how a service is controlled and the commands used to control it. We will then return to the higher level and offer a bit more breadth.

systemd commands are issued using systemctl, just like upstart commands were issued using initctl. The most basic systemctl commands are very similar to the corresponding upstart [initctl] commands. (We will see that the similarity ends shortly, but enjoy it while you can...)

systemd operates on units, which are described in a unit file. There are a total of 12 types of units. We will begin by discussing the most important [and familiar] of these units: the service unit. A unit has state. It may be active, inactive, activating, deactivating or failed.

The service unit controls a service. It would be equivalent to a subsystem or to an upstart script. Using systemctl you can get status, start, stop or restart a service by name. As an example, lets look at the sshd service, which should be pretty familiar:

In this output you can see all the stats of the sshd service, including when it was started, what its state is, where the service file is, what is control group is and what the pid is. It even shows you a cronology of the state changes sshd reported (started, listening...)

You might surmise from this that it is simple to restart the service: systemctl restart sshd. (Note: the complete command would be systemctl restart sshd.service  but you can omit the .service extension if the unit is a service.) You'd be correct. In addition, to ease the transition from system5 init scripts to systemd, the service command exists and redirects you to the equivalent systemctl command:

[root@localhost ~]# service sshd restart
Redirecting to /bin/systemctl restart  sshd.service
[root@localhost ~]#