Slide 1
Slide 1 text
systemd: The Good Parts
James Nugent
Samsung Electronics
@jen20
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
Fedora 15 May 2011
openSUSE 12.2 September 2012
CentOS 7.14.04 April 2014
Red Hat Enterprise Linux 7.0 June 2014
SUSE Linux Enterprise Server 12 October 2014
Debian 8 April 2015
Ubuntu 15.04 April 2015
systemd Adop+on
Slide 8
Slide 8 text
Fedora 15 May 2011
openSUSE 12.2 September 2012
CentOS 7.14.04 April 2014
Red Hat Enterprise Linux 7.0 June 2014
SUSE Linux Enterprise Server 12 October 2014
Debian 8 April 2015
Ubuntu 15.04 April 2015
systemd Adop+on
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
systemd
Slide 12
Slide 12 text
Aspects of systemd
• System and service manager
• This is what we’ll focus on today
• So2ware pla6orm for developing other applica9ons
• We’ll touch on this too
• “Glue” between the kernel and user applica9ons
• Some references at the end
Slide 13
Slide 13 text
Units
Slide 14
Slide 14 text
Units
Slide 15
Slide 15 text
Unit File Paths
• /lib/systemd/system
• For package-installed units
• /etc/systemd/system
• For Administrator-configured units
• /run/systemd/system
• For non-persistent run9me modifica9ons
Slide 16
Slide 16 text
name.type
Slide 17
Slide 17 text
name.type
consul.service
Slide 18
Slide 18 text
name.type
ssh.socket
Slide 19
Slide 19 text
Service Units
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Service Unit Types
• Simple (default) - for executables which run without
daemonising - like Consul.
• Forking - for executables which daemonise themselves
• Oneshot - usually short-lived programs which run to comple9on
and terminate
• No+fy - for executables which will no9fy systemd when they
are started and available for work.
• Consul now supports this - more later!
Slide 24
Slide 24 text
Unit Commands
• systemctl enable consul.service
• systemctl start consul.service
• systemctl stop consul.service
• systemctl restart consul.service
• systemctl status consul.service
Slide 25
Slide 25 text
systemctl status consul.service
Slide 26
Slide 26 text
systemctl status consul.service
Unit Name & Descrip9on
Slide 27
Slide 27 text
systemctl status consul.service
Unit Name & Descrip9on Enabled Status
Slide 28
Slide 28 text
systemctl status consul.service
Unit Name & Descrip9on Enabled Status
Up9me
Slide 29
Slide 29 text
systemctl status consul.service
Unit Name & Descrip9on Enabled Status
Up9me
All processes
Slide 30
Slide 30 text
systemctl status consul.service
Unit Name & Descrip9on Enabled Status
Up9me
All processes
Last 10 log lines
Slide 31
Slide 31 text
“Drop-in” ConfiguraGon
Slide 32
Slide 32 text
“Drop-in” Configura+on
Slide 33
Slide 33 text
“Drop-in” Configura+on
Per-Service Drop-In
Configura9on Directory
Slide 34
Slide 34 text
“Drop-in” Configura+on
Loaded Drop-in
Configura9on Files
Slide 35
Slide 35 text
systemd-delta
Slide 36
Slide 36 text
Common Bootstrapping PaGern
• Install so2ware from a generic package
• apt-get install consul
• Install bootstrapping script and drop-in configura9on from an
environment-specific package
• apt-get install consul-bootstrap-aws
• apt-get install consul-bootstrap-azure
Slide 37
Slide 37 text
Working Example
Slide 38
Slide 38 text
Target Units
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
consul-online.target
network-online.target
consul.service
multi-user.target
consul-online.service
service-that-depends-on-consul.service
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
Socket Units
Slide 45
Slide 45 text
If a service dies, its listening socket stays
around, not losing a single message. After
a restart of the crashed service it can
continue right where it left off. If a service
is upgraded we can restart the service
while keeping around its sockets, thus
ensuring the service is continously
responsive. Not a single connection is lost
during the upgrade.
—Lennart Poettering
Slide 46
Slide 46 text
If a service dies, its listening socket stays
around, not losing a single message. After
a restart of the crashed service it can
continue right where it left off. If a service
is upgraded we can restart the service
while keeping around its sockets, thus
ensuring the service is continously
responsive. Not a single connection is lost
during the upgrade.
Slide 47
Slide 47 text
If a service dies, its listening socket stays
around, not losing a single message. After
a restart of the crashed service it can
continue right where it left off. If a service
is upgraded we can restart the service
while keeping around its sockets, thus
ensuring the service is continously
responsive. Not a single connection is lost
during the upgrade.
Slide 48
Slide 48 text
Permissions
Slide 49
Slide 49 text
Socket Ac+va+on in Go
Credit: Vincent Bernat - “IntegraBon of a Go Service with systemd” - 2018
Slide 50
Slide 50 text
Socket Ac+va+on in Go
Credit: Vincent Bernat - “IntegraBon of a Go Service with systemd” - 2018
Slide 51
Slide 51 text
$ go build 404.go
$ systemd-socket-activate -l 8000 ./404
Listening on [::]:8000 as 3
$ curl '[::1]':8000
404 page not found
$ curl '[::1]':8000
404 page not found
Slide 52
Slide 52 text
Service Unit
Slide 53
Slide 53 text
Socket Unit
Slide 54
Slide 54 text
Graceful Shutdown
Slide 55
Slide 55 text
Timer Units
Slide 56
Slide 56 text
Timer Units
Slide 57
Slide 57 text
This talk only scratches the
surface of the capabiliGes of
systemd
Slide 58
Slide 58 text
THANK YOU!
Slide 59
Slide 59 text
References
• https://freedesktop.org/wiki/Software/systemd/
• https://github.com/jen20/hashidays-nyc
• https://github.com/hashicorp/consul/pull/3164
• https://vincent.bernat.im/en/blog/2018-
systemd-golang-socket-activation