Comparing systemd to Traditional init

Some of the benefits of systemd over the traditional System V init facility include:

  • systemd never loses initial log messages
  • systemd can respawn daemons as needed
  • systemd records runtime data (i.e., captures stdout/stderr of processes)
  • systemd doesn't lose daemon context during runtime
  • systemd can kill all components of a service cleanly

Here are some details of how systemd compares to pre-RHEL 7 init and related commands:

  • System startup: The systemd process is the first process ID (PID 1) to run on RHEL 7 system. It initializes the system and launches all the services that were once started by the traditional init process.

  • Managing system services: For RHEL 7, the systemctl command replaces service and chkconfig. Prior to RHEL 7, once RHEL was up and running, the service command was used to start and stop services immediately. The chkconfig command was used to identify at which run levels a service would start or stop automatically.
    Although you can still use the service and chkconfig commands to start/stop and enable/disable services, respectively, they are not 100% compatible with the RHEL 7 systemctl command. For example, non-standard service options, such as those that start databases or check configuration files, may not be supported in the same way for RHEL 7 services.

  • Changing runlevels: Prior to RHEL 7, runlevels were used to identify a set of services that would start or stop when that runlevel was requested. Instead of runlevels, systemd uses the concept of targets to group together sets of services that are started or stopped. A target can also include other targets (for example, the multi-user target includes an nfs target).
    There are systemd targets that align with the earlier runlevels. However the point of targets is not to necessarily imply a level of activity (for example, runlevel 3 implied more services were active than runlevel 1). Instead targets just represent a group of services, so it's appropriate that there are many more targets available than there are runlevels. The following list shows how systemd targets align with traditional runlevels:

    Traditional runlevel      New target name     Symbolically linked to...
    Runlevel 0           |    runlevel0.target -> poweroff.target
    Runlevel 1           |    runlevel1.target -> rescue.target
    Runlevel 2           |    runlevel2.target -> multi-user.target
    Runlevel 3           |    runlevel3.target -> multi-user.target
    Runlevel 4           |    runlevel4.target -> multi-user.target
    Runlevel 5           |    runlevel5.target -> graphical.target
    Runlevel 6           |    runlevel6.target -> reboot.target
    
  • Default runlevel: The default runlevel (previously set in the /etc/inittab file) is now replaced by a default target. The location of the default target is /etc/systemd/system/default.target, which by default is linked to the multi-user target.

  • Location of services: Before systemd, services were stored as scripts in the /etc/init.d directory, then linked to different runlevel directories (such as /etc/rc3.d, /etc/rc5.d, and so on). Services with systemd are named something.service, such as firewalld.service, and are stored in /lib/systemd/system and /etc/systemd/system directories. Think of the /lib files as being more permanent and the /etc files as the place you can modify configurations as needed.
    When you enable a service in RHEL 7, the service file is linked to a file in the /etc/systemd/system/multi-user.target.wants directory. For example, if you run systemctl enable fcoe.service a symbolic link is created from /etc/systemd/system/multi-user.target.wants/fcoe.service that points to /lib/systemd/system/fcoe.service to cause the fcoe.service to start at boot time.
    Also, the older System V init scripts were actual shell scripts. The systemd files tasked to do the same job are more like .ini files that contain the information needed to launch a service.

  • Configuration files: The /etc/inittab file was used by the init process in RHEL 6 and earlier to point to the initialization files (such as /etc/rc.sysinit) and runlevel service directories (such as /etc/rc5.d) needed to start up the system. Changes to those services was done in files (usually named after the service) in the /etc/sysconfig directory. For systemd in RHEL 7, there are still files in /etc/sysconfig used to modify how services behave. However, services can be modified by adding files to the /etc/systemd directory to override the permanent service files in the /lib/systemd directories.

Transitioning to systemd

If you are used to using the init process and System V init scripts prior to RHEL 7, there are a few things you should know about transitioning to systemd:

  • Using RHEL 6 commands: For the time being, you can use commands such as service, chkconfig, runlevel, and init as you did in RHEL 6. They will cause appropriate systemd commands to run, with similar, if not exactly the same, results. Here are some examples:

    # service cups restart
    Redirecting to /bin/systemctl restart cups.service
    # chkconfig cups on
    Note: Forwarding request to 'systemctl enable cups.service'.
    
  • System V init Scripts: Although not encouraged, System V init scripts are still supported. There are still some services in RHEL 7 that are implemented in System V init scripts. To see System V init scripts that are available on your system and the runlevels on which they start, use the chkconfig command as follows:

    # chkconfig --list
    ...
    iprdump       0:off   1:off   2:on   3:on   4:on   5:on   6:off
    iprinit       0:off   1:off   2:on   3:on   4:on   5:on   6:off
    iprupdate     0:off   1:off   2:on   3:on   4:on   5:on   6:off
    netconsole    0:off   1:off   2:off  3:off  4:off  5:on   6:off
    network       0:off   1:off   2:on   3:on   4:on   5:on   6:off
    rhnsd         0:off   1:off   2:on   3:on   4:on   5:on   6:off
    ...
    

Using chkconfig, however, will not show you the whole list of services on your system. To see the systemd-specific services, run the systemctl list-unit-files command, as described earlier.