Sign in Subscribe
Linux

Linux SysV init and Systemd essentials

System V init and Systemd are two important softwares in the Linux. They start essential system programs during boot and ensure they are always running. Here we give you the essential information for easy administration and show you how to find specific documentations to go further.

Gmk Ziz 👓

• 9 min read
Linux SysV init and Systemd essentials
Photo by Emma Francis / Unsplash

Introduction

One of the responsibilities of 'System V init' (SysV init) and 'Systemd' is to initialize the operating system. Initializing the operating system means starting essential system or users enabled programs/services, during the boot process and making sure they are always running.

They also provide userspace tools for managing those services (stop, restart, get status...). 'SysV init' is old (1983). 'Systemd' is new, comes with many new and interesting features, is very well documented and being adopted step by step by many Linux distributions as 'SysV init' replacement.

Systemd

For more about Systemd, have a look at the manual with the 'man systemd' command. For web version, have a look at Systemd manual online.

Systemd runs as 'system' or 'user' instance, depending on the value of it's current 'PID'. It is running as 'system' instance if the 'PID' is '1', otherwise as 'user' instance.

When running as 'system' instance, the service manager will look for it's configuration file inside the following directories:

  • /etc/systemd/
  • /lib/systemd/
  • /run/systemd/

The following configuration files will be interpreted:

  • For 'system' instance:

    • /etc/systemd/system.conf
    • /etc/systemd/system.conf.d/*.conf
    • /lib/systemd/system.conf.d/*.conf
    • /run/systemd/ystem.conf.d/*.conf

  • For 'user' instance:

    • /etc/systemd/user.conf
    • /etc/systemd/user.conf.d/*.conf
    • /lib/systemd/user.conf.d/*.conf
    • /run/systemd/user.conf.d/*.conf

For configuration files inside the drop-in '.conf.d' directories, those in '/etc' will take precedence over those in '/run' whose in turn will take precedence over those in '/lib'. Which means that, if the same configuration file (same file name) is present in all drop-in directories, the one in '/etc' will override the others.

Units overview

Systemd use an abstraction called 'unit' to manage programs/services. 'Unit files' are used to configure systemd's managed programs/services.

A unit file is a plain text ini-style file that encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd, a resource management slice or a group of externally created processes.

Systemd has therefore different unit types (11 at the time of writting) as we can see in the previous definition of a 'unit file'. Below are some descriptions about some of them, taken from systemd's manual:

  • service: start and control daemons and the processes they consist of
  • target: useful to group units, or provide well-known synchronization points during boot-up
  • socket: encapsulate local IPC or network sockets in the system, useful for socket-based activation
  • mount: control mount points in the file system
  • automount: provide automount capabilities, for on-demand mounting of file systems as well as parallelized boot-up
  • device: expose kernel devices in systemd and may be used to implement device-based activation
  • timer: useful for triggering activation of other units based on timers

Through those units types, we got an little overview of what systemd is capable of. Use the following command for details on a particular unit type:

man systemd.UNIT-TYPE # with UNIT-TYPE=service,target,socket...

Unit files naming and directories

The naming convention for systemd unit files is this:

  • my_chosen_unit_name.UNIT-TYPE

with 'UNIT-TYPE' matching one of the systemd's units types. Here are some examples:

  • nginx.service
  • vpn.socket

Here are some directories from where unit files will be searched:

  • /etc/systemd/system: main directory for unit files. Units of installed packages will be linked here from '/usr/lib/systemd/system' and '/usr/local/lib/systemd/system'
  • /run/systemd/system: runtime units configurations. Erased after reboot.
  • /usr/lib/systemd/system: unit files of some installed packages will go there (sources for files linked into '/etc/systemd/system')
  • /usr/local/lib/systemd/system: unit files of some installed packages will go there (sources for files linked into '/etc/systemd/system')

Previouly listed directories are for systemd instance running in 'system' mode. For the equivalent in 'user' mode, simply replace 'system' by 'user'. To see all units load paths, run the following commands:

# system mode
systemd-analyze --system unit-paths

# user mode
systemd-analyze --user unit-paths

Units administration

The 'systemctl' command is used for units adminitration. Units adminitration include:

  • start, stop, reload, get status
  • list, show content, show dependencies, edit
  • Get, set unit properties
  • Get, set current and default target (or runlevel)
  • Create units

A 'drop-in' configuration file is a file inside a directory whose name ends with '.d', in order to extend a systemd daemon configuration file or units configurations files. Ex: 'systemd-timesyncd.service.d/disable-with-time-daemon.conf' will extend the 'systemd-timesyncd.service' unit configuration file

Start, stop, reload, restart, status, list
# start, stop, reload, restart, status
systemctl start/stop/reload/restart/status UNIT-NAME[.UNIT-TYPE]

# List units
systemctl list-units

# List units of type 'service'
systemctl -t service list-units
Show content, edit, list dependencies
# Show configuration files of a specific unit.
# Will show all loaded configuration files content
# including those inside drop-in (.d) directories
systemctl cat UNIT-NAME

# Edit unit. A new drop-in file will be created and 
# the existing UNIT configuration will be extended
systemctl edit EXISTING-UNIT-NAME

# Open original unit config file for editing 
# instead of creating a drop-in file
systemctl edit --full UNIT-NAME

# Create a new unit configuration file. --force will 
# open a new file for editing if the unit doesn't exist
systemctl edit --force NEW-UNIT-NAME

# Edit unit temporarily. Changes will be made 
# temporarily in /run and lost after reboot
systemctl edit --runtime UNIT-NAME

# List dependencies of a specific unit
systemctl list-dependencies UNIT-NAME
Enable and disable units
# Disable => not loaded at boot
systemctl disable UNIT-NAME

# Enable => loaded at boot
systemctl enable UNIT-NAME

# Verify
systemctl is-enabled UNIT-NAME
List unit properties, override unit properties
# Show all properties of a specific unit
systemctl show UNIT-NAME

# Show a specific property of a unit
systemctl show -p PROPERTY-NAME UNIT-NAME

# List of all available porperties for a unit type
systemctl show SOME-UNIT-TYPE

# Get unit resources control properties only
# Properties to limit cpu and ram of a specific unit for instance
man systemd.resource-control

# Set, update a unit property value
systemctl set-property PROPERTY-NAME=VALUE [PROPERTY-NAME-N=VALUE-N]
Get, set current and default target (or runlevel)
# For available targets and their descriptions
man systemd.special

# Get the default target the system will boot into
systemctl get-default

# Set the default target for the system to boot into
systemctl set-default TARGET

# Immediately change the current target to graphical (runlevel 5)
systemctl isolate graphical.target
Creating units

For details about that specific unit type configuration file and all available configuration directives for systemd units, repectively, use:

# Configuration of a specific unit type
man systemd.UNIT-TYPE

# Units confiuration directives
man systemd.directives
Reload systemd daemon after unit files change
systemctl daemon-reload

Systemd retro compatibility with SysV init scripts

See 'man systemd-sysv-generator' and 'man systemd-generator' for details.

The SysV init scripts directory: '/etc/init.d', will be scanned by systemd at boot or after a systemd reload. Found scripts will be converted to systemd service units. Systemd will respect start priorities and start/stop runlevels of the SysV init scripts when converting them to systemd service units, by adding dependencies and 'WantedBy' targets to the units configuration files.

Systemd uses 'generators' (small executables) living inside the 'system-generator' directory, inside Systemd's configurations base directories ('/run/systemd', '/lib/systemd', '/etc/systemd', etc). The 'SourcePath=' directive will be included in generated unit files to specify the source SysV init script the systemd unit configuration is being generated from.

Systemd journald administration

Show disk usage of all journal files
journalctl --disk-usage
Reduce journal disk usage below specified size
$ journalctl --vacuum-size=BYTES

# BYTES could be for instance:
# 1000000000 or 1000000K or 1000M or 1G

# Example

$ journalctl --disk-usage
Archived and active journals take up 136.0M in the file system.

$ journalctl --vacuum-size=100M
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal/ab68fa6922910fdc74007141e78c1993.

$ journalctl --disk-usage
Archived and active journals take up 136.0M in the file system.

# No cleanup made because the size of the archived journal are not enough to satisfy the request
# We can also include currently active journal files by using the --rotate option in order to archive 
# them before performing the cleanup

# Rotate currently active journals and do cleanup after
$ journalctl --vacuum-size=100M --rotate
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Deleted archived journal /var/log/journal/ab68fa6922910fdc74007141e78c1993/user-1003@90c851b0208a4330a7b7f8c824105cdb-00000000002cde8d-00060ef8c085a4b2.journal (104.0M).
Vacuuming done, freed 104.0M of archived journals from /var/log/journal/ab68fa6922910fdc74007141e78c1993.

$ journalctl --disk-usage
Archived and active journals take up 72.0M in the file system.
Keep only the specified number of journal files
$ journalctl --vacuum-files=INT

# Example

$ journalctl --vacuum-files=1
Vacuuming done, freed 0B of archived journals from /var/log/journal/ab68fa6922910fdc74007141e78c1993.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Remove journal files older than specified time
$ journalctl --vacuum-time=TIME

# TIME could be for instance:
# 2days or 2d, 2months or 2m, 40minutes or 40m...
# Detailed info about TIME format can be found using 'man systemd.time'

# Example

$ journalctl --vacuum-time=7d
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal/ab68fa6922910fdc74007141e78c1993.

Some useful systemd man pages

  • systemd.special: special systemd units (available targets and their explanations)
  • systemd.UNIT-TYPE: documentation of a particular systemd unit type
  • systemd.directives: index of all available systemd unit files configuration directives and where we can find explanations about them
  • systemd.index: index of all manpages from the systemd project
  • systemd.exec: systemd units processes execution environment configuration directives (privileges, OutOfMemory (OOM) policy, limits, scheduling, sandboxing, filtering, environment variables, logging, etc)

SysV init

Overview of SysV init service scripts directories

  • /etc/init.d: directory where sysV init scripts resides
debian:~$ ll /etc/init.d/
total 160
-rwxr-xr-x 1 root root 5336 févr.  1  2016 alsa-utils
-rwxr-xr-x 1 root root 2014 mai   29  2017 anacron
-rwxr-xr-x 1 root root 3617 avril 12  2017 auditd
-rwxr-xr-x 1 root root 2401 janv. 23  2017 avahi-daemon
-rwxr-xr-x 1 root root 2948 sept. 13  2017 bluetooth
(...)
  • /etc/rcX.d (debian based distributions) or /etc/rc.d/rcX.d (redhat based distributions):
    • contains symbolic links to init scripts inside '/etc/init.d'
    • symbolic links names start with 'S' or 'K' followed by a two digit priority number and the init script name
    • 'S' means run the script. 'K' means do not run or stop the script
    • the priority number indicates the order in which init scripts will be run at boot. Scripts with the same priority number will be executed in parallel. Those with lower number before those with higher number ('S01bobo' before 'S04baba' for instance).
    • The 'X' in 'rcX.d' directory filename represents a runlevel number. There is one directory for each runlevel defined by the 'LSB (Linux Standard Base)' specification. Therefore symbolic links in 'rcX.d' will be used only for the specified 'X' runlevel.
debian:~$ ll /etc/rc
rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/ rcS.d/

# The following init script links will 
# only be ran at boot in runlevel 5
debian:~$ ll /etc/rc5.d/
total 0
lrwxrwxrwx 1 root root 17 déc.  22  2018 S01anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root 16 août   7  2020 S01auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 22 déc.  22  2018 S01avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 19 déc.  22  2018 S01bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 24 août   4  2019 S01cgroupfs-mount -> ../init.d/cgroupfs-mount
(...)

Get, set system execution level (runlevel)

  • To get the current system runlevel, the 'runlevel' command can be used
  • System default boot runlevel can be set inside the '/etc/inittab' file
  • To change runlevel while the system is already up and running, the 'init ' command can be used

SysV init service scripts administration

  • The 'service' utility can be used to start, stop, restart, reload or get the status of a SysV init service
  • The 'update-rc.d' utility can be used to make a SysV init script start (or not) at boot, at the default or a specific runlevel for debian based distributions
  • The 'chkconfig' utility can be used to make a SysV init script start (or not) at boot, at the default or a specific runlevel for Red Hat based distributions
# Enable/Disable a SysV init service on every runlevel
chkconfig <service-name> off/on

# Enable/Disable a SysV init service at a specific runlevel
chkconfig <service-name> --level <runlevel-number> off/on

# List SysV init services managed by chkconfig
# and their statuses (on, off) on each runlevel
chkconfig --list

# Make chkconfig manage a specific SysV init service
chkconfig --add <service-name>

Sign up for more like this.

Enter your email
Subscribe