SystemD - Services

> Operating System - Kernel (Windows, Unix, Linux) > Linux / Unix > Linux - Boot (Init service system) > SystemD

1 - About

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.

Advertising

3 - Unit Management

3.1 - Properties

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”.
Advertising

3.2 - Unit file

systemctl cat foobar.service
/etc/systemd/system/foobar.service
[Unit]
Description=foobar daemon
After=network.target
 
[Service]
Type=forking
User=infa
; 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
TimeoutSec=infinity
TimeoutStartSec=10min 10sec
 
[Install]
WantedBy=multi-user.target

3.3 - Unit file path

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

3.4 - Type

3.4.1 - oneshot

3.4.2 - forking

3.5 - Environment

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

4 - Service Management

The command line tool that manage SystemD is called systemctl.

4.1 - Listing

  • query the state of all services, both systemd native and SysV/LSB services
systemctl
  • 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
Advertising

4.2 - Show

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

4.3 - Timeout

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.

Example

; 15 min
TimeoutSec=900 

4.4 - Dependency

systemctl list-dependencies sshd.service
sshd.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
. . .

4.5 - Start

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)

4.6 - Stop

systemctl stop foobar.service

4.7 - Restart

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

4.8 - Reload

  • Reload config file
sudo systemctl reload foobar.service

4.9 - Active

systemctl is-active application.service

4.10 - Failed

systemctl is-failed application.service

4.11 - Enable

Whether the service should start on boot.

sudo systemctl enable foobar.service
 
# isEnabled
systemctl is-enabled application.service

4.12 - Disable

sudo systemctl disable foobar.service

4.13 - Status

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

4.14 - Install

  • 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

5 - Documentation / Reference