Systemd overview

Contents
1. Systemd is..
2. Systemd Unit
3. Boot process with systemd
4. Service management
5. Resource management
6. Log management
7. Systemd Snapshots
8. Target
9. Timer

1. systemd is …
• what is systemd?
- Already the basis of Fedora, RHEL, CentOS, OpenSUSE and much
embedded.
- Soon to be the basis of Debian and Ubuntu.
- after OpenStack and Docker, the most discussed new Linux
feature.

1. systemd is …
• what is systemd?
- System and Service manager.
- systemd is compatible with SysV and LSB init scripts.
- modular.
- asynchronous and concurrent.
- descripbed by declarative sets of properties.
- features a is independent of languages API.

1. systemd is …
• philosophy
Extract duplicate functionality from individual daemons
and move it to the systemd core or the Linux Kernel.

1. systemd is …
• What is systemd?
- Provides parallelization capabilities.
- Uses socket and D-Bus activation for starting services.
- Offers on-demand starting of daemons.
- Implements transactional dependency-based service control logic.
- Tracks processes using Linux cgroups.
- Supports snapshotting and restoring.
- Maintains mount and automount points.

2. Systemd Unit
• Units
- Units are the objects that systemd knows how to manage.
- systemd based around the notion of units.
- units have a name and a type.

2. Systemd Unit
• Units
- A unit configuration file 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

2. Systemd Unit
• Unit path
- /usr/lib/systemd/system/: units provided by installed packages
- /etc/systemd/system/: units installed by the system administrator

• Unit file list
file describe
.service how to manage a service or application on the server.
.socket
A network or IPC socket, or a FIFO buffer that systemd uses for socket-
based activation.
.device
A device that has been designated as needing systemd management
by udev or the sysfs filesystem.
.mount defines a mountpoint on the system to be managed by systemd.
.automount configures a mountpoint that will be automatically mounted.
.swap swap space on the system.
2. Systemd Unit

• Unit file list
file describe
.target
Used to provide synchronization points for other units when booting
up or changing states.
.timer
Defines a timer that will be managed by systemd, similar to a cron job
for delayed or scheduled activation.
.snapshot Created automatically by the systemctl snapshot command.
.slice
Associated with Linux Control Group nodes, allowing resources to be
restricted or assigned to any processes associated with the slice.
.scope
Created automatically by systemd from information received from its
bus interfaces.
2. Systemd Unit

• General Characteristics of Unit Files
- Section names are well defined and case-sensitive.
- Within these sections, unit behavior and metadata is defined
through the use of simple directives using a key-value format.
[Section]
Directive1=value
Directive2=value
2. Systemd Unit

• Unit file structure
지시자 설명
[Unit]
- Unit의 type에 의존적이지 않는 일반적인 옵션을 포함.
- Init 을 설명하고 Unit의 동작을 정의.
- 다른 유닛과의 Dependency 설정.
[Unit type]
- 특정 유닛이 type-specific 지시자를 가지고 있다면 해당 옵션에 대한 항목
을 참조하여 유닛파일을 작성하거나 파악해야 함.
[Install]
- 인스톨 관련 정보.
- systemctl enable과 disasble에 의한 동작 기술되어 있음.
2. Systemd Unit

• SysVinit
- The init process is started by the kernel.
- Reads /etc/inittab to find the default run level.
- Reads the files starting with S in /etc/rc.d/rc${initdefault}.d
- Executes each one in order, on at a time.

• upstart
- Makes booting faster by encoding dependencies between
modules.
- upstart then resolves these dependencies and start up as many
things as it can in parallel.

• upstart - problem
- Encoding the dependencies.
- Still starting too much.

• Systemd
- A new init system for Linux.
- Makes booting faster.
(Start processes in parallel, start fewer processes)
To start less.
And to start more in parallel.

• Systemd
- Starting less means starting fewer services or deferring the
starting of services until they are actually needed.
- if we have to run something, we should not serialize its start-up
(as sysvinit does), but run it all at the same time, so that the
available CPU and disk IO bandwidth is maxed out, and hence the
overall start-up time minimized.

1. The BIOS initialization.
2. MBR reads information from Grub or LILO boot
loader and initializes the kernel.
3. The very first target executed by systemd
is default.target.
default.target is actually a symlink to
graphical.target.

4. multi-user.target has been invoked This target
sets the environment for multi user support.
multi-user.target passes control to another layer
basic.target.requirement
after
multi-user.target has been invoked and this target
keep its further sub-units.

5. "basic.target" unit is the one that starts usual
services specially graphical manager service.
basic.target passes on control to sysinit.target.
requirement
6. "sysinit.target" starts important system services
like file System mounting, swap spaces and devices,
kernel additional options etc.
sysinit.target passes on startup process to local-
fs.target.
after
requirement
after

7. local-fs.target , no user related services are started
by this target unit, it handles core low level services
only. This target is the one performing actions on
the basis of /etc/fstab and /etc/inittab files.
requirement
after
requirement
after

• The minimum execution unit of systemd
- Various tasks in the SysVinit’s system initialization scripts are extracted and
defined as independent ‘Unit’s.

• Socket Activation
- Socket activation makes it possible to start all services completely
simultaneously, without any kind of ordering.
- Much more powerful is socket activation when used for all local
services including those which need to be started anyway on
boot.

• Socket Activation – Traditional SysV
- Traditional SysV-based system only
one service can be in the process of
getting started at a time.
- The following serialization of startup
would take place

• Socket Activation – Upstart
upstart
- Certain distributions tried to improve
this strictly serialized start-up
- The parallelization is increased, the
overall startup time slightly smaller.

• Socket Activation - Systemd
- Socket activation makes it possible to start
all four services completely simultaneously,
without any kind of ordering.
- the creation of the listening sockets is
moved outside of the daemons themselves
we can start them all at the same time, and
they are able to connect to each other's
sockets right-away.
Syslog
D-bus
service
socket

• a number of other benefits
- no longer need to configure dependencies.
- If a service dies its listening socket stays around, not losing a
message.
- Not a single connection is lost during the upgrade.
- We can even replace a service during runtime in a way that is
invisible to the client.

- Modern daemons on Linux tend to provide services via D-Bus
instead of AF_UNIX sockets.
- Using bus activation a service can be started the first time it is
accessed.
- Bus activation gives us the minimal per-request synchronisation we
need for starting up the providers and the consumers of D-Bus
services at the same time
• Parallelizing Bus Service

CUPS
Avahi
CUPSAvahi
D-Bus
D-bus Queue
If CUPS is quicker than Avahi via the bus activation logic we can get D-
Bus to queue the request until Avahi manages to establish its service
name.
• Parallelizing Bus Service

- File-system related jobs: mounting, fscking, quota.
- A lot of time is spent idling to wait until all devices that are listed in
/etc/fstab show up in the device tree and are then fsck'ed, mounted,
quota checked (if enabled).
- After that is fully finished we go on and boot the actual services.
- Improve this using the venerable autofs system.
• Parallelizing File system

• Parallelizing File system - autofs
- autofs is a program for automatically mounting directories on an
as-needed basis.
open()
wait.. All Filesystem ready
File 1
autofs
Service A
open()
File 1
Service A
All filesystem
File system
ready

• Parallelizing File system - autofs
- This way we can begin starting our daemons even before all file
systems have been fully made available -- without them missing
any files, and maximizing parallelization.

4. Service Management
• Service Management
- For service management tasks, the target unit will be service units.
- These are the most obvious kind of unit: daemons that can be started,
stopped, restarted, reloaded

• Starting and Stopping Services
- To start a systemd service, executing instructions in the service's
unit file, use the start command.
$sudo systemctl start application.service
$sudo systemctl start application

• Starting and Stopping Services
- To stop a currently running service, can use the stop command
instead.
$sudo systemctl stop application

• Restarting and Reloading
- To restart a currently running service, can use the restart command.
$sudo systemctl restart application.service

• Restarting and Reloading
- If the application in question is able to reload its configuration
files (without restarting), can issue the reload command to initiate
that process:
$sudo systemctl reload application.service

• Enabling and Disabling
- To start services automatically at boot, must enable them.
- This will create a symbolic link from the system's copy of the service file
into the location on disk where systemd looks for autostart files
$sudo systemctl enable application.service

• Enabling and Disabling
- To disable the service from starting automatically.
- This will remove the symbolic link that indicated that the service should
be started automatically.
$sudo systemctl disable application.service

• Checking the Status of Services
- To check the status of a service on your system, you can use the status
command.
$systemctl status application.service

• Listing Current Units
- To see a list of all of the active units that systemd knows about, we can
use the list-units command.
$systemctl list-units

• Listing Current Units
- The output has the following columns.
UNIT The systemd unit name.
LOAD Whether the unit's configuration has been parsed by systemd.
ACTIVE A summary state about whether the unit is active.
SUB
This is a lower-level state that indicates more detailed information
about the unit.
DESCRIPTION A short textual description of what the unit is/does.

• Cgroup
- According to the Linux kernel documentation
: "Control Groups provide a mechanism for aggregating/partitioning
sets of tasks, and all their future children, into hierarchical groups
with specialized behaviour.“
- cgroups is a Linux kernel feature that limits, accounts for, and
isolates the resource usage (CPU, memory, disk I/O, network, etc.) of
a collection of processes.

• Cgroup
- Isolate a set of processes that tend to manage resource
consumption, restricting resource use to a preconfigured limit.
- Assign sufficient memory or processing resources.
- Allocate network or storage bandwidth.
- Track assigned resources.
- Restrict device access to specific users or groups

• Cgroup

• systemd’s Resource Control Concepts
- systemd organizes processes with cgroups.
- systemd provides three unit types that are useful for the purpose of
resource control.
Service
a number of processes that are started and stopped by
systemd based on configuration.
Scope
a number of processes that are started and stopped by
arbitrary processes via fork(), and then registered at
runtime with PID1.
Slices
be used to group a number of services and scopes
together in a hierarchical tree.

• systemd’s Resource Control Concepts
- Service, scope and slice units directly map to objects in the
cgroup tree.

• Previously, with sysVinit
- No tracking of which service started which processes.
- Hard to completely terminate a service.
- No resources limitation, which is per-process, not per-service.

• Cgroup and Systemd
- Tracking and killing all processes created by each service.
- Per-service accounting and resources allocation/limitation.
- Isolate user sessions – Kill all user processes.

- A central part of a system that starts up and maintains services
should be process babysitting.
- It should watch services.
- If they crash it should collect information about them.
• Keeping Track of Processes

6. Log management
• Log management mechanism of systemd
- systemd intercepts messages to stdout/stderr and rsyslogd
- The message are sent to its own logging service.
- “systemd-journald.service” or “journald”

6. Log management
• Traditional system log flow
Process
/dev/log
rsyslogd

6. Log management
• System log flow under systemd
Process
/dev/log
systemd /run/systemd/journal/syslog
rsyslogd

6. Log management
• Imjournal: Systemd Journal Input Module
Process
/dev/log
systemd /run/systemd/journal/syslog
rsyslogd
- The latest rsyslogd can directly access journald’s database using
‘imjournal’ module.

6. Log management
• Journal
- systemd has its own logging system called the journal
- Show all messages from this boot :
$ journalctl -b
- Show all messages from date :
$ journalctl --since="2016-01-30 18:17:16"

6. Log management
• Journal
- Show all messages since 20 minutes ago :
$ journalctl --since "20 min ago"
- Follow new messages :
$ journalctl -f
- Show all messages by a specific executable :
$ journalctl /usr/lib/systemd/systemd

6. Log management
• Journal
- Show all messages by a specific process :
$ journalctl _PID=1
- Show all messages by a specific unit :
$ journalctl -u netcfg
- Show kernel ring buffer :
$ journalctl -k

• Systemd Snapshots
- Snapshots can be used to save or rollback the state of all services
and units of the system.
- Systemd snapshots have two inteded use cases :
To allow a user to temporarily enter a specific state such as “Emergency Shell”,
terminating current services, and provide an easy way to return to the state
before, pulling up all services again that got temporarily pulled down.

- Snapshot units are not configured via unit configuration files.
- A unit whose name ends in ".snapshot" refers to a dynamic
snapshot of the systemd runtime state.
- Snapshots are not configured on disk but created dynamically.
$ systemd snapshot name

- When created, they will automatically get dependencies on the
currently activated units.
- They act as saved runtime state of the systemd manager.

8. Target
• Target
- systemd uses targets which serve a similar purpose as runlevels.
- Each target is named instead of numbered and is intended to
serve a specific purpose with the possibility of having multiple
ones active at the same time.
- Get current targets :
$systemctl list-units –type=target

8. Target
• Target
- The standard target is default.target, which is aliased by default
to graphical.target.
- Change current target :
- This will only change the current target, and has no effect on the
next boot.
$systemctl isolate xxx.target

8. Target
• Target
- Leave the bootloader alone and change default.target. This can
be done using systemctl:
$systemctl set-default xxx.target

• Power management
- Shut down and reboot the system:
$systemctl reboot
- Shut down and power-off the system :
$systemctl poweroff
8. Target

8. Target
• Power management
- Suspend the system :
$systemctl suspend
- Put the system into hibernation
$systemctl hibernate
- Put the system into hybrid-sleep state(or suspend-to both)
$systemctl hybrid-sleep

9. Timer
• Timer
- Although cron is arguably the most well-known job scheduler,
systemd timers can be an alternative.
- Monotonic timers :
activate after a time span relative to a varying starting point.
- Realtime timers :
activate on a calendar event (like cronjobs).

9. Timer
• Timer
- To view all started timers :
$systemctl list-timers

9. Timer
• Timer benefits
- Jobs can be easily started independently of their timers.
- Each job can be configured to run in a specific environment.
- Jobs can be attached to cgroups.
- Jobs can be set up to depend on other systemd units.
- Jobs are logged in the systemd journal for easy debugging.

9. Timer
• Example
- Monotonic timer : A timer which will start 15 minutes after boot
and again every week while the system is running.
[Unit]
Description=Run foo weekly and on boot
[Timer]
OnBootSec=15min
OnUnitActiveSec=1w
[Install]
WantedBy=timers.target

9. Timer
• Example
- Realtime timer : A timer which starts once a week (at 12:00am on
Monday).
[Unit]
Description=Run foo weekly
[Timer]
OnCalendar=weekly
Persistent=true
[Install]
WantedBy=timers.target

참고 정보
- Your first dive into systemd | Etsufi Nakai
- Systemd with RHEL 7 | 박현익
- https://fedoraproject.org/wiki/Packaging:Systemd
- http://0pointer.de/blog/projects/systemd.html
- http://linoxide.com/linux-how-to/systemd-boot-process/
- https://www.digitalocean.com/community/tutorials/understanding-systemd-units-
and-unit-files
- http://blog.fpmurphy.com/2013/09/systemd-snapshots.html#ixzz46tOBI500

• [Unit type] Section
Appendix

• [Install] Section
Appendix

• [Service] Section
- simple: The main process of the service is specified in the start line. This is the default if
the Type= and Busname= directives are not set, but the ExecStart= is set. Any
communication should be handled outside of the unit through a second unit of the
appropriate type (like through a .socket unit if this unit must communicate using
sockets).
- forking: This service type is used when the service forks a child process, exiting the
parent process almost immediately. This tells systemd that the process is still running
even though the parent exited.
- oneshot: This type indicates that the process will be short-lived and that systemd
should wait for the process to exit before continuing on with other units. This is the
default Type= and ExecStart= are not set. It is used for one-off tasks.
Appendix

- dbus: This indicates that unit will take a name on the D-Bus bus. When this happens,
systemd will continue to process the next unit.
- notify: This indicates that the service will issue a notification when it has finished
starting up. The systemd process will wait for this to happen before proceeding to
other units.
- idle: This indicates that the service will not be run until all jobs are dispatched.
- RemainAfterExit=: This directive is commonly used with the oneshot type. It indicates
that the service should be considered active even after the process exits.
- PIDFile=: If the service type is marked as "forking", this directive is used to set the path
of the file that should contain the process ID number of the main child that should be
monitored.
Appendix

- BusName=: This directive should be set to the D-Bus bus name that the service will
attempt to acquire when using the "dbus" service type.
- NotifyAccess=: This specifies access to the socket that should be used to listen for
notifications when the "notify" service type is selected This can be "none", "main", or
"all. The default, "none", ignores all status messages. The "main" option will listen to
messages from the main process and the "all" option will cause all members of the
service's control group to be processed.
- ExecStart=: This specifies the full path and the arguments of the command to be
executed to start the process. This may only be specified once (except for "oneshot"
services). If the path to the command is preceded by a dash "-" character, non-zero exit
statuses will be accepted without marking the unit activation as failed.
Appendix

- ExecStartPre=: This can be used to provide additional commands that should be
executed before the main process is started. This can be used multiple times. Again,
commands must specify a full path and they can be preceded by "-" to indicate that
the failure of the command will be tolerated.
- ExecStartPost=: This has the same exact qualities as ExecStartPre= except that it
specifies commands that will be run after the main process is started.
- ExecReload=: This optional directive indicates the command necessary to reload the
configuration of the service if available.
- ExecStop=: This indicates the command needed to stop the service. If this is not given,
the process will be killed immediately when the service is stopped.
Appendix

- ExecStopPost=: This can be used to specify commands to execute following the stop
command.
- RestartSec=: If automatically restarting the service is enabled, this specifies the amount
of time to wait before attempting to restart the service.
- Restart=: This indicates the circumstances under which systemd will attempt to
automatically restart the service. This can be set to values like "always", "on-success",
"on-failure", "on-abnormal", "on-abort", or "on-watchdog". These will trigger a restart
according to the way that the service was stopped.
- TimeoutSec=: This configures the amount of time that systemd will wait when stopping
or stopping the service before marking it as failed or forcefully killing it. You can set
separate timeouts with TimeoutStartSec= and TimeoutStopSec= as well.
Appendix

• [Socket] Section
- ListenStream=: This defines an address for a stream socket which supports sequential,
reliable communication. Services that use TCP should use this socket type.
- ListenDatagram=: This defines an address for a datagram socket which supports fast,
unreliable communication packets. Services that use UDP should set this socket type.
- ListenSequentialPacket=: This defines an address for sequential, reliable communication
with max length datagrams that preserves message boundaries. This is found most
often for Unix sockets.
- ListenFIFO: Along with the other listening types, you can also specify a FIFO buffer
instead of a socket.
Appendix

• [Socket] Section
- Accept=: This determines whether an additional instance of the service will be started
for each connection. If set to false (the default), one instance will handle all connections.
- SocketUser=: With a Unix socket, specifies the owner of the socket. This will be the root
user if left unset.
- SocketGroup=: With a Unix socket, specifies the group owner of the socket. This will be
the root group if neither this or the above are set. If only the SocketUser= is set,
systemd will try to find a matching group.
- SocketMode=: For Unix sockets or FIFO buffers, this sets the permissions on the created
entity.
- Service=: If the service name does not match the .socket name, the service can be
specified with this directive.
Appendix

• [Mount] Section
- What=: The absolute path to the resource that needs to be mounted.
- Where=: The absolute path of the mount point where the resource should be mounted.
This should be the same as the unit file name, except using conventional filesystem
notation.
- Type=: The filesystem type of the mount.
- Options=: Any mount options that need to be applied. This is a comma-separated list.
- SloppyOptions=: A boolean that determines whether the mount will fail if there is an
unrecognized mount option.
- DirectoryMode=: If parent directories need to be created for the mount point, this
determines the permission mode of these directories.
- TimeoutSec=: Configures the amount of time the system will wait until the mount
operation is marked as failed.
Appendix

• [Automount] Section
- Where=: The absolute path of the automount point on the filesystem. This will match
the filename except that it uses conventional path notation instead of the translation.
- DirectoryMode=: If the automount point or any parent directories need to be created,
this will determine the permissions settings of those path components.
Appendix

• [Swap] Section
- What=: The absolute path to the location of the swap space, whether this is a file or a
device.
- Priority=: This takes an integer that indicates the priority of the swap being configured.
- Options=: Any options that are typically set in the /etc/fstab file can be set with this
directive instead. A comma-separated list is used.
- TimeoutSec=: The amount of time that systemd waits for the swap to be activated
before marking the operation as a failure.
Appendix

• [Path] Section
- PathExists=: This directive is used to check whether the path in question exists. If it
does, the associated unit is activated.
- PathExistsGlob=: This is the same as the above, but supports file glob expressions for
determining path existence.
- PathChanged=: This watches the path location for changes. The associated unit is
activated if a change is detected when the watched file is closed.
- PathModified=: This watches for changes like the above directive, but it activates on file
writes as well as when the file is closed.
- DirectoryNotEmpty=: This directive allows systemd to activate the associated unit when
the directory is no longer empty.
Appendix

• [Path] Section
- Unit=: This specifies the unit to activate when the path conditions specified above are
met. If this is omitted, systemd will look for a .service file that shares the same base
unit name as this unit.
- MakeDirectory=: This determines if systemd will create the directory structure of the
path in question prior to watching.
- DirectoryMode=: If the above is enabled, this will set the permission mode of any path
components that must be created.
Appendix

• [Timer] Section
- OnActiveSec=: This directive allows the associated unit to be activated relative to
the .timer unit's activation.
- OnBootSec=: This directive is used to specify the amount of time after the system is
booted when the associated unit should be activated.
- OnStartupSec=: This directive is similar to the above timer, but in relation to when the
systemd process itself was started.
- OnUnitActiveSec=: This sets a timer according to when the associated unit was last
activated.
- OnUnitInactiveSec=: This sets the timer in relation to when the associated unit was last
marked as inactive.
- OnCalendar=: This allows you to activate the associated unit by specifying an absolute
instead of relative to an event.
Appendix

• [Timer] Section
- AccuracySec=: This unit is used to set the level of accuracy with which the timer should
be adhered to. By default, the associated unit will be activated within one minute of the
timer being reached. The value of this directive will determine the upper bounds on the
window in which systemd schedules the activation to occur.
- Unit=: This directive is used to specify the unit that should be activated when the timer
elapses. If unset, systemd will look for a .service unit with a name that matches this unit.
- Persistent=: If this is set, systemd will trigger the associated unit when the timer
becomes active if it would have been triggered during the period in which the timer
was inactive.
- WakeSystem=: Setting this directive allows you to wake a system from suspend if the
timer is reached when in that state.
Appendix

Systemd overview

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Systemd overview

Similar to Systemd overview (20)

Recently uploaded

Recently uploaded (20)

Systemd overview

Editor's Notes