SystemD - Services


systemd is a suite of software to manage the init process.

This page is about the Service unit type of SystemD .service (ie about systemd.service)

It is designed to replace and be backwards compatible with SysV init scripts. Traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization.

In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system.

Unit Management


Units are representations of resources that systemd knows about.

A Systemd output may show the following columns

  • UNIT: The systemd unit name
  • LOAD: Loaded in memory ?
  • ACTIVE: Does the unit has been successfuly processed ?
  • SUB: State information that varies by unit
  • DESCRIPTION: description of the unit
  • STATE: state of a unit file:
    • “enabled”,
    • “disabled”,
    • “static”:
      • ie the unit file does not contain an “install” section and therefore the unit cannot be enabled
      • used for single action or as a dependency of another units
    • or “masked”.

Unit file

systemctl cat foobar.service
Description=foobar daemon

; sleep for 5 minutes to ensure headnode is up and running
ExecStartPre=/bin/sleep 300
ExecStart=/usr/bin/daemon startup
ExecStart=/usr/bin/daemon shutdown
TimeoutStartSec=10min 10sec


Example for java with redirections

ExecStart=/bin/sh -c 'exec /bin/java -jar xxx.jar -Xmx512M -Xms32M >> /data/logs/xxx.log 2>&1'

Unit file path

  • /usr/lib/systemd/ for files that ships with packages
  • /etc/systemd/system/ for admin modification
  • /lib/systemd/ ??



  • The process started by the command is the main process
  • The process should not be run in the background but in the foreground
  • The service is considered up immediately


  • The command will create a child process that will run as the main service process,
  • The service manager will consider the unit started when the parent process exits.


  • same as simple but the service considered up after the systemd terminate the launch.


Environment variable possibilities can be seen here: SystemD - Environment Variable for a service

Standard Stream

Redirection of the standard stream of the application.

To query it, see SystemD - Journalctl


  • Create a new file
  • Append

Service Management

The command line tool that manage SystemD is called systemctl.


  • query the state of all services, both systemd native and SysV/LSB services
  • List services
systemctl list-units --all --type=service
#-all because list-units command shows only active units by default

# State
systemctl list-units --all --state=inactive
  • To see every unit file if something goes wrong
systemctl list-unit-files


  • unit file
systemctl cat foobar.service
  • Service properties
systemctl show sshd.service


You cannot used infinity for the timeout everywhere

# all timeout property
systemctl show node.service | grep -i Timeout*

# By property
systemctl show node.service -p TimeoutStartSec
systemctl show node.service -p TimeoutStopSec
systemctl show node.service -p TimeoutSec # A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value
# ''-p --property=NAME''  Show only properties by this name
  • JobTimeoutUSec
  • TimeoutStartSec Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. Default to DefaultTimeoutStartSec from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default . Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Pass “infinity” to disable the timeout logic.


; 15 min


systemctl list-dependencies sshd.service
. . .


sudo systemctl start foobar.service

# as systemd knows to look for *.service files for service management commands
sudo systemctl start foobar

Fail If the start fails, systemctl will give you a generic error message:

systemctl start foo.service
Job failed. See system journal and 'systemctl status' for details.

By default:

  • the stdout, stderr of services are directed to the systemd journal (journalctl command)
  • the logs that services produce via syslog go by default to /var/log/messages and to the SystemD Journal
  • systemd stores the exit code of failed services.

Next step:

  • Run systemctl status as root or as a user from the adm group to get a journal extract
systemctl status foo.service
  • or list the journal with the journalctl command.
journalctl --unit foo
  • or list the syslog message (default to /var/log/messages)


systemctl stop foobar.service


sudo systemctl restart foobar.service

# if you don't know
sudo systemctl reload-or-restart application.service


  • Reload config file
sudo systemctl reload foobar.service


systemctl is-active application.service


systemctl is-failed application.service


Whether the service should start on boot.

sudo systemctl enable foobar.service

# isEnabled
systemctl is-enabled application.service


sudo systemctl disable foobar.service

Ansible - Disable if exists

- name: Populate service facts

- name: Disable firewalld
  when: "'firewalld.service' in services"
    name: firewalld
    enabled: no
    state: stopped


systemctl status application.service

Example with cron

systemctl status crond.service
● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-02-20 14:56:00 UTC; 1 weeks 6 days ago
 Main PID: 6339 (crond)
   CGroup: /system.slice/crond.service
           └─6339 /usr/sbin/crond -n


  • Copy the unit script to /etc/systemd/system/
cp foobar.service /etc/systemd/system/
  • Restart systemd:
systemctl daemon-reload
  • Enable het script voor autorun:
systemctl enable infaservice
  • The service can be managed via
systemctl [start|stop|status] foobar


Documentation / Reference

Powered by ComboStrap