2. Outline
1 Introduction
2 Behind the scenes: cgroups
3 Managing services
4 Analyzing startup performance
5 Exploring the system status
6 Configuring services by writing unit files
7 Timer units
8 Socket activation
9 Logging with journald
10 Containers integration
11 Networking with systemd-networkd
12 Migration from sysvinit
13 Conclusions
Lucas Nussbaum systemd 2 / 40
3. Init system
First process started by the kernel (pid 1)
Responsible for bringing up the rest of userspace
Mounting filesystems
Starting services
. . .
Also the parent for orphan processes
Traditional init system on Linux: sysVinit
Inherited from Unix System V
With additional tools (insserv, startpar) to handle
dependencies and parallel initialization
Lucas Nussbaum systemd 3 / 40
4. systemd
Written (since 2010) by Lennart Poettering (Red Hat) and others
Now the default on most Linux distributions
Shifts the scope from starting all services (sysVinit) to
managing the system and all services
Key features:
Relies on cgroups for
Services supervision
Control of services execution environment
Declarative syntax for unit files more efficient/robust
Socket activation for parallel services startup
Nicer user interface (systemctl & friends)
Additional features: logging, timer units (cron-like), user sessions
handling, containers management
Lucas Nussbaum systemd 4 / 40
5. Behind the scenes: cgroups
Abbreviated from control groups
Linux kernel feature
Limit, account for and isolate processes and their resource usage
(CPU, memory, disk I/O, network, etc.)
Related to namespace isolation:
Isolate processes from the rest of the system
Chroots on steroids
PID, network, UTS, mount, user, etc.
LXC, Docker ≈ cgroups + namespaces (+ management tools)
Lucas Nussbaum systemd 5 / 40
6. cgroups and systemd
Each service runs in its own cgroup
Enables:
Tracking and killing all processes created by each service
Per-service accounting and resources allocation/limitation
Previously, with sysVinit:
No tracking of which service started which processes
PID files, or hacks in init scripts: pidof / killall / pgrep
Hard to completely terminate a service (left-over CGI
scripts when killing Apache)
No resources limitation (or using setrlimit (= ulimit), which
is per-process, not per-service)
Also isolate user sessions kill all user processes (not by default)
More information: Control Groups vs. Control Groups and
Which Service Owns Which Processes?
Lucas Nussbaum systemd 6 / 40
9. Managing services with systemctl
What is being manipulated is called a unit: services (.service),
mount points (.mount), devices (.device), sockets (.socket), etc.
Basic commands:
sysVinit systemd notes
service foo start systemctl start foo
service foo stop systemctl stop foo
service foo restart systemctl restart foo
service foo reload systemctl reload foo
service foo condrestart systemctl condrestart foo restart if already running
update-rc.d foo enable systemctl enable foo auto-start at next boot
update-rc.d foo disable systemctl disable foo disable auto-start
systemctl is-enabled foo
There’s auto-completion (apache2 and apache2.service work)
Several services can be specified:
systemctl restart apache2 postgresql
Lucas Nussbaum systemd 9 / 40
10. systemd and runlevels
With sysVinit, runlevels control which services are started
automatically
0 = halt; 1 = single-user / minimal mode; 6 = reboot
Debian: no difference by default between levels 2, 3, 4, 5
RHEL: 3 = multi-user text, 5 = multi-user graphical
systemd replaces runlevels with targets:
Configured using symlinks farms in
/etc/systemd/system/target.wants/
systemctl enable/disable manipule those symlinks
systemctl mask disables the service and prevents it from
being started manually
The default target can be configured with
systemctl get-default/set-default
More information: The Three Levels of "Off"
Lucas Nussbaum systemd 10 / 40
11. Default targets (bootup(7))
local -fs-pre.target
|
v
(various mounts and (various swap (various cryptsetup
fsck services ...) devices ...) devices ...) (various low -level (various low -level
| | | services: udevd , API VFS mounts:
v v v tmpfiles , random mqueue , configfs ,
local -fs.target swap.target cryptsetup.target seed , sysctl , ...) debugfs , ...)
| | | | |
__________________|_________________ | ___________________|____________________/
|/
v
sysinit.target
|
____________________________________ /| ________________________________________
/ | | |
| | | | |
v v | v v
(various (various | (various rescue.service
timers ...) paths ...) | sockets ...) |
| | | | v
v v | v rescue.target
timers.target paths.target | sockets.target
| | | |
__________________|_________________ | ___________________/
|/
v
basic.target
|
____________________________________ /| emergency.service
/ | | |
| | | v
v v v emergency.target
display - (various system (various system
manager.service services services)
| required for |
| graphical UIs) v
| | multi-user.target
| | |
_________________ | _________________/
|/
v
graphical.target
Lucas Nussbaum systemd 11 / 40
12. Analyzing startup performance
Fast boot matters in some use-cases:
Virtualization, Cloud:
Almost no BIOS / hardware checks only software
startup
Requirement for infrastructure elasticity
Embedded world
systemd-analyze time: summary
Startup finished in 4.883s (kernel) + 5.229s (userspace) = 10.112s
systemd-analyze blame: worst offenders
2.417s systemd -udev -settle.service
2.386s postgresql@9 .4-main.service
1.507s apache2.service
240ms NetworkManager.service
236ms ModemManager.service
194ms accounts -daemon.service
Lucas Nussbaum systemd 12 / 40
13. systemd-analyze plot
Similar to bootchartd, but does not require rebooting with a
custom init= kernel command-line
Lucas Nussbaum systemd 13 / 40
15. Exploring the system status
Listing units with systemctl list-units (or just systemctl):
active units: systemctl
List only services: systemctl -t service
List units in failed state: systemctl --failed
Whole system overview: systemctl status
GUI available: systemadm
Lucas Nussbaum systemd 15 / 40
16. systemctl status service
Includes:
Service name and description, state, PID
Free-form status line from systemd-notify(1) or sd_notify(3)
Processes tree inside the cgroup
Last lines from journald (syslog messages and stdout/stderr)
Lucas Nussbaum systemd 16 / 40
17. Configuring services by writing unit files
With sysVinit: shell scripts in /etc/init.d/
Long and difficult to write
Redundant code between services
Slow (numerous fork() calls)
With systemd: declarative syntax (.desktop-like)
Move intelligence from scripts to systemd
Covers most of the needs, but shell scripts can still be used
Can use includes and overrides (systemd-delta)
View config file for a unit: systemctl cat atd.service
Or just find the file under /lib/systemd/system/ (distribution’s
defaults) or /etc/systemd/system (local overrides)
Lucas Nussbaum systemd 17 / 40
18. Simple example: atd
[Unit]
Description=Deferred execution scheduler
# Pointer to documentation shown in systemctl status
Documentation=man:atd(8)
[Service]
# Command to start the service
ExecStart =/usr/sbin/atd -f
IgnoreSIGPIPE=false # Default is true
[Install]
# Where "systemctl enable" creates the symlink
WantedBy=multi -user.target
Lucas Nussbaum systemd 18 / 40
19. Common options
Documented in systemd.unit(5) ([Unit]), systemd.service(5)
([Service]), systemd.exec(5) (execution environment)
Show all options for a given service:
systemctl show atd
Sourcing a configuration file:
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
Using the $MAINPID magic variable:
ExecReload=/bin/kill -HUP $MAINPID
Auto-restart a service when crashed: (≈ runit / monit)
Restart=on-failure
Conditional start:
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
Conditions on architecture, virtualization, kernel cmdline, AC power, etc.
Lucas Nussbaum systemd 19 / 40
20. Options for isolation and security
Use a network namespace to isolate the service from the network:
PrivateNetwork=yes
Use a filesystem namespaces:
To provide a service-specific /tmp directory:
PrivateTmp=yes
To make some directories inaccessible or read-only:
InaccessibleDirectories=/home
ReadOnlyDirectories=/var
Specify the list of capabilities(7) for a service:
CapabilityBoundingSet=CAP_CHOWN CAP_KILL
Or just remove one:
CapabilityBoundingSet=~CAP_SYS_PTRACE
Disallow forking:
LimitNPROC=1
Lucas Nussbaum systemd 20 / 40
21. Options for isolation and security (2)
Run as user/group: User=, Group=
Run service inside a chroot:
RootDirectory=/srv/chroot/foobar
ExecStartPre=/usr/local/bin/setup-foobar-chroot.sh
ExecStart=/usr/bin/foobard
RootDirectoryStartOnly=yes
Control CPU shares, memory limits, block I/O, swapiness:
CPUShares=1500
MemoryLimit=1G
BlockIOWeight=500
BlockIOReadBandwith=/var/log 5M
ControlGroupAttribute=memory.swappiness 70
More information: Converting sysV init scripts to systemd service
files, Securing your services, Changing roots, Managing
resources
Lucas Nussbaum systemd 21 / 40
22. Timer units
Similar to cron, but with all the power of systemd (dependencies,
execution environment configuration, etc)
Realtime (wallclock) timers: calendar event expressions
Expressed using a complex format (see systemd.time(7)),
matching timestamps like: Fri 2012-11-23 11:12:13
Examples of valid values: hourly (= *-*-* *:00:00), daily (=
*-*-* 00:00:00), *:2/3 (= *-*-* *:02/3:00)
Monotonic timers, relative to different starting points:
5 hours and 30 mins after system boot: OnBootSec=5h 30m
50s after systemd startup: OnstartupSec=50s
1 hour after the unit was last activated: OnUnitActiveSec=1h
(can be combined with OnBootSec or OnStartupSec to ensure
that a unit runs on a regular basis)
Lucas Nussbaum systemd 22 / 40
23. Timer units example
myscript.service:
[Unit]
Description=MyScript
[Service]
Type=simple
ExecStart =/usr/local/bin/myscript
myscript.timer:
[Unit]
Description=Runs myscript every hour
[Timer]
# Time to wait after booting before we run first time
OnBootSec =10min
# Time between running each consecutive time
OnUnitActiveSec =1h
Unit=myscript.service
[Install]
WantedBy=multi -user.target
Lucas Nussbaum systemd 23 / 40
24. Timer units example (2)
Start timer:
systemctl start myscript.timer
Enable timer to start at boot:
systemctl enable myscript.timer
List all timers:
systemctl list-timers
Lucas Nussbaum systemd 24 / 40
25. Socket activation
systemd listens for connection on behalf of service until the
service is ready, then passes pending connections
Benefits:
No need to express ordering of services during boot:
They can all be started in parallel faster boot
And they will wait for each other when needed (when
they will talk to each other), thanks to socket activation
Services that are seldomly used do not need to keep running,
and can be started on-demand
Not limited to network services: also D-Bus activation and path
activation
More information: Converting inetd Service, Socket Activation for
developers (+ follow-up)
Lucas Nussbaum systemd 25 / 40
27. Socket activation example: sshd
sshd.socket:
[Unit]
Description=SSH Socket for Per -Connection Servers
[Socket]
ListenStream =22
Accept=yes
[Install]
WantedBy=sockets.target
sshd@.service:
[Unit]
Description=SSH Per -Connection Server
[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket
Lucas Nussbaum systemd 27 / 40
28. Socket activation example: sshd (2)
sshd@.service means that this is an instantiated service
There’s one instance of sshd@.service per connection:
# systemctl --full | grep ssh
sshd@172 .31.0.52:22 -172.31.0.4:47779. service loaded active running
sshd@172 .31.0.52:22 -172.31.0.54:52985. service loaded active running
sshd.socket loaded active listening
Instanciated services are also used by getty
See Serial console and Instanciated services
Lucas Nussbaum systemd 28 / 40
29. Logging with journald
Component of systemd
Captures syslog messages, kernel log messages, initrd and early
boot messages, messages written to stdout/stderr by all services
Forwards everything to syslog
Structured format (key/value fields), can contain arbitrary data
But viewable as syslog-like format with journalctl
Indexed, binary logs; rotation handled transparently
Can replace syslog (but can also work in parallel)
Not persistent across reboots by default – to make it persistent,
create the /var/log/journal directory, preferably with:
install -d -g systemd-journal /var/log/journal
setfacl -R -nm g:adm:rx,d:g:adm:rx /var/log/journal
Can log to a remote host (with systemd-journal-gateway, not in
Debian yet)
Lucas Nussbaum systemd 29 / 40
31. Using journalctl
View the full log: journalctl
Since last boot: journalctl -b
For a given time interval: journalctl --since=yesterday
or journalctl --until="2013-03-15 13:10:30"
View it in the verbose (native) format: journalctl -o verbose
Filter by systemd unit: journalctl -u ssh
Filter by field from the verbose format:
journalctl _SYSTEMD_UNIT=ssh.service
journalctl _PID=810
Line view (≈ tail -f): journalctl -f
Last entries (≈ tail): journalctl -n
Works with bash-completion
See also: Journald design document, Using the Journal
Lucas Nussbaum systemd 31 / 40
32. Containers integration
General philosophy: integrate management of services from
machines (VMs and containers) with those of the host
systemd-machined: tracks machines, provides an API to list,
create, register, kill, terminate machines, transfer images (tar,
raw, Docker)
machinectl: command-line utility to manipulate machines
other tools also have containers support:
systemctl -M mycontainer restart foo
systemctl list-machines: provides state of containers
journalctl -M mycontainer
journalctl -m: combined log of all containers
systemd has its own mini container manager: systemd-nspawn
Other virtualization solutions can also talk to machined
More information: Container integration
Lucas Nussbaum systemd 32 / 40
33. Networking with systemd-networkd
Replacement for /etc/network/interfaces, on servers and VMs
Not really for Network Manager on desktops and laptops
Supports setting IP configuration, configuring bridges, vlans,
bonding, tunnels, etc
Configuration files with a [Match] section to match on MAC
address, driver, udev path, type, hostname, etc
foo.link: link-level configuration – MAC address, interface
name, MTU, rate, Duplex mode, Wake on Lan
foo.netdev: creation of virtual network devices (bridges,
bonds, vlans, IPIP or GRE tunnels, VXLAN, tun, tap, veth)
foo.network: network devices configuration: IP (static or
DHCP, gateway, additional routes, DNS), addition to bridge
More information: systemd-networkd(8), systemd.link(5),
systemd.network(5), systemd.netdev(5)
Lucas Nussbaum systemd 33 / 40
34. Example 1: DHCP, additional route
For higher performance, systemd includes a DHCP client
# /etc/systemd/network/ethernet.network
[Match]
Name=eth0
[Network]
DHCP=yes
[Route]
Gateway =192.168.1.253
Destination =10.0.0.0/8
Lucas Nussbaum systemd 34 / 40
35. Example 2: static addressing and VLAN
# /etc/systemd/network/vlan1.netdev
# [Match] section is optional in netdev files
[NetDev]
Name=vlan1
Kind=vlan
[VLAN]
Id=1
# /etc/systemd/network/ethernet.network
[Match]
Name=eth0
[Network]
DHCP=yes
VLAN=vlan1 # will create vlan1 on this device
# /etc/systemd/network/vlan1.network
[Match]
Name=vlan1
[Network]
Address =192.168.1.1/24
Gateway =192.168.1.254
Lucas Nussbaum systemd 35 / 40
36. Example 3: bridge and tap
# /etc/systemd/network/bridge0.netdev
[NetDev]
Name=bridge0
Kind=bridge
# /etc/systemd/network/bridge0.network
[Match]
Name=bridge0
[Network]
Address =192.168.1.1/24
DHCPServer=yes # systemd has its own , very basic , DHCP server
# /etc/systemd/network/tap.netdev
[NetDev]
Name=tap0
Kind=tap
# /etc/systemd/network/tap.network
[Match]
Name=bridge0
[NetDev]
Bridge=bridge0
Lucas Nussbaum systemd 36 / 40
37. Migration from sysvinit
systemd hooks into LSB init scripts: service foo start|stop|...
and /etc/init.d/foo redirect to systemctl
systemd-sysv-generator creates wrapper units for LSB scripts:
Using LSB dependencies
Services are described as LSB: foo
List all generated services:
systemctl list-units | grep LSB:
Lucas Nussbaum systemd 37 / 40
39. More stuff
New cross-distro configuration files: /etc/hostname,
/etc/locale.conf, /etc/sysctl.d/*.conf,
/etc/tmpfiles.d/*.conf
Tools to manage hostname, locale, time and date: hostnamectl,
localectl, timedatectl
Support for watchdogs
Handling of user sessions
Each within its own cgroup
Multi-seat support
loginctl to manage sessions, users, seats
Lucas Nussbaum systemd 39 / 40
40. Conclusions
systemd revisits the way we manage Linux systems
If we redesigned services management from scratch, would it
look like systemd?
For service developers: easier to support systemd than sysVinit
No need to fork, to drop privileges, to write a pid file
Just output logs to stdout (redirected to syslog, with priorities)
Some parts still have rough edges, or are still moving targets, but
are promising: journal, containers, networking
systemd might not be the final answer, but at least it’s an
interesting data point to look at
Lucas Nussbaum systemd 40 / 40
