Article ID: 124440, created on Feb 11, 2015, last review on Sep 10, 2015

  • Applies to:
  • Operations Automation
  • Plesk
  • Virtuozzo
  • Virtuozzo containers


This article explains what is systemd, provides basic information on its configuration and commands, and explains which Odin products support Systemd.


Systemd is a system initialization service. It starts services when Linux server boots up, and stops them when the server shuts down.

Systemd replaces SysV and Upstart initialization systems in CentOS starting from CentOS 7. Systemd is also the default init system in most modern Linux distributions - openSUSE, Ubuntu, and Fedora. Debian will use systemd by default starting from Debian 8 (Jessie).

Compared to other initialization systems, the benefits of systemd are:

  • Backwards compatibility with SysV init. This means that scripts in /etc/init.d, as well as commands such as telinit, service and chkconfig are still working.
  • Parallel start of the services. This allows the system to start very quickly.
  • Good services dependency resolution mechanism. Package maintainers and system administrators do not need to manually configure in which order init starts the services. Systemd calculates dependencies and starts the services in proper order.
  • D-Bus activation. Services that use D-Bus protocol for inter-process communication can be started on-demand, when client application tries to contact the service.
  • Socket-based activation. Systemd listens on services' sockets and passes these sockets to services when they start. This means that services won't lose messages/packets that were sent to them during restart, since systemd caches messages that cannot be delivered to the service.


Systemd uses the following terminology:

  • Units - configuration units of systemd. Units can represent services, targets (see below), mountpoints, devices, paths watched for changes, snapshots etc.

  • Targets - collection of units. Targets are the analogue of runlevels in SysV init, but there can be much more than seven and several targets can be active at the same time. When you switch on a target, the units inside of it are activated.



Management of systemd and its settings is done with systemctl command. Here are several most often used commands:

  • Start service:

    # systemctl start nginx

  • Check service status with information about the file in which the service is defined, status of the service and backtrace of commands with exit codes:

    # systemctl status nginx

  • See if the service is started:

    # systemctl is-active nginx

  • Restart service:

    # systemctl restart nginx

  • Stop service:

    # systemctl stop nginx

  • Enable service (analogue of "chkconfig nginx on"):

    # systemctl enable nginx

  • List all services (analogue of "chkconfig --list"):

    # systemctl list-units --type=service --all

  • List all available targets:

    # systemctl list-units --type=target --all

  • Enable target (start units inside this target)

    # systemctl enable

  • Switch to target (stop all other targets except the one we want; analogue of switching to a runlevel with telinit):

    # systemctl isolate


Another useful command is journalctl, which allows querying systemd logs. Here are the most useful commands:

  • Continuous list of all log messages from nginx service (works like "tail -f"):

    # journalctl -f -u nginx

  • List last 10 messages in systemd log with extended status descriptions:

    # journalctl -xn

  • Show all logs generated by httpd executable:

    # journalctl /usr/sbin/httpd


Here is the example of output from systemctl when nginx does not start, because other process listens on port 80:

[root@plesk-12 ~]# systemctl start nginx
Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.

[root@plesk-12 ~]# systemctl status nginx
nginx.service - Startup script for nginx service
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Fri 2015-02-06 03:55:27 EST; 21s ago
  Process: 1933 ExecStopPost=/bin/echo Service nginx stopped (code=exited, status=0/SUCCESS)
  Process: 1852 ExecStartPost=/bin/echo Service nginx started (code=exited, status=0/SUCCESS)
  Process: 2011 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
  Process: 2008 ExecStartPre=/usr/sbin/nginx -q -t (code=exited, status=0/SUCCESS)
  Process: 2005 ExecStartPre=/usr/bin/test $NGINX_ENABLED = yes (code=exited, status=0/SUCCESS)
  Process: 2002 ExecStartPre=/bin/echo Starting nginx service (code=exited, status=0/SUCCESS)
 Main PID: 1850 (code=exited, status=0/SUCCESS)

Feb 06 03:55:25 plesk-12 echo[2002]: Starting nginx service
Feb 06 03:55:25 plesk-12 nginx[2011]: nginx: [emerg] bind() to failed (98: Address already in use)
Feb 06 03:55:25 plesk-12 nginx[2011]: nginx: [emerg] bind() to failed (98: Address already in use)
Feb 06 03:55:26 plesk-12 nginx[2011]: nginx: [emerg] bind() to failed (98: Address already in use)
Feb 06 03:55:26 plesk-12 nginx[2011]: nginx: [emerg] bind() to failed (98: Address already in use)
Feb 06 03:55:27 plesk-12 nginx[2011]: nginx: [emerg] bind() to failed (98: Address already in use)
Feb 06 03:55:27 plesk-12 nginx[2011]: nginx: [emerg] still could not bind()

This output of the status command alone is enough to determine the cause of the problem.

Configuration files


Configuration files can be found in the following directories:

  • /etc/systemd/system – this directory contains units created by system administrator. Units in this directory take utmost precedence and override units found in other directories.
  • /run/systemd/system – this directory contains units created by systemd or services during runtime.
  • /usr/lib/systemd/system – this directory contains units installed from RPM/DEB packages. These units can be overridden by units in /run/systemd/system and /etc/systemd/system.


Services are configured in *.service files, that in the context of systemd serve the same purpose as rc scripts in SysV (e.g. /etc/init.d/nginx), but are much simpler to write and understand.

Here's the file for nginx web server with additional comments. You can find more information on the structure of this file and available options in systemd manual.

Description=Startup script for nginx service  # These targets must be enabled for this service  # Start after these targets

Type=forking  # Tells systemd how the service starts. In this case the command 
              # configured in ExecStart below will fork the service process 
              # and exit.
Restart=no    # Don't try to restart the service if it didn't start properly.


EnvironmentFile=/etc/sysconfig/nginx  # Analog of ". /etc/sysconfig/nginx" in rc script

.include /etc/sysconfig/nginx.systemd

# These are executed when service starts
ExecStartPre=/bin/echo 'Starting nginx service'
ExecStartPre=/usr/bin/test $NGINX_ENABLED = "yes"
ExecStartPre=/usr/sbin/nginx -q -t
ExecStartPost=/bin/echo "Service nginx started"

# These - when it reloads
ExecReload=/bin/echo "Reloading nginx service"
ExecReload=/usr/bin/test $NGINX_ENABLED = "yes"
ExecReload=/usr/sbin/nginx -q -t
ExecReload=/usr/bin/pkill -F ${NGINX_PID_FILE} --signal HUP

# And this - when it stops.
# You may have noticed that we have only 'echo' command here.
# This is because systemd takes care of shutting down the process.
ExecStopPost=/bin/echo 'Service nginx stopped'

[Install]  # Which target to start this service with.

Systemd and Odin products


Plesk supports systemd starting from Plesk 11.5 (on openSUSE systems) and Plesk 12 (on CentOS).

Plesk services (psa, nginx, sw-engine) are managed by systemd same way as the other services. Service configuration files can be found in directory /usr/lib/systemd/system/ .

Services messages, which would be typically collected by syslogd service, are collected by systemd-journald and are available through journalctl command, as well as in the files inside /var/log/ directory.

Plesk services are not collected in a special target and started together with, the default target for server installations.

Virtuozzo and Virtuozzo Containers

At the moment, neither Virtuozzo or Virtuozzo Containers can be installed on CentOS 7. Both products do not support systemd. However, systemd-enabled operating systems can be installed in virtual machines and containers.

Odin Service Automation and Plesk Automation

At the moment, Odin Service Automation and Plesk Automation do not support CentOS 7 on their service and infrastructure nodes.

Search Words

centos 7



debian 8


d02f9caf3e11b191a38179103495106f 2897d76d56d2010f4e3a28f864d69223 e0aff7830fa22f92062ee4db78133079 caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae 614fd0b754f34d5efe9627f2057b8642 0dd5b9380c7d4884d77587f3eb0fa8ef a914db3fdc7a53ddcfd1b2db8f5a1b9c 56797cefb1efc9130f7c48a7d1db0f0c

Email subscription for changes to this article
Save as PDF