SystemD - Services


This page is about service management with the systemd 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
ExecStop=/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


see SystemD - Journalctl

Documentation / Reference

Discover More
How to disable your firewall in rescue mode ?

When working with firewalls, the unexpected can happen and you can be locked out of your server or vps. Many VPS provider provides a rescue mode that permits to rescue your server. This how-to shows you...
Init - SysV init Script

The init script are bash script that are run by the init daemon. see See sudo Each script will be run as a command and the structure of the command will look like: Where command is the actual...
Linux - Boot (Init service system)

The Init system is the first process (as PID 1) started by a operating system at system startup that start all other service (ie services) The following are possible init system: bash...
Bash Liste Des Attaques Ovh
Linux Utility - Crontab (Cron) Scheduler

The cron is a scheduler daemon that gets its data from crontab files where each users have their own crontab. Crontab is the command line application that is used to install, deinstall or list the...
Bash Liste Des Attaques Ovh
Sudo - How to allow a user to manage a service ?

How to allow a user to manage a service with sudo sudo is a program that defines rules over what a user may run as command. It allows to add sudoer file (configruation file) into the directory /etc/sudoers.d...
SystemD - Conf

systemd configuration /etc/systemd/system.conf
SystemD - Environment Variable for a service

How to add environment to a service within SystemD where : ...
SystemD - Target A .target unit configuration file is used for: grouping units via dependencies (useful as boot targets) establish standardized names for synchronization points used in dependencies...
SystemD - Timer

To start a service at a scheduled time Doc: systemd.timer The matching .service is: by default the name of the timer (e.g. foo.service for foo.timer) or is specified in the [Timer] section by...

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

Share this page:
Follow us:
Task Runner