merge(systemd-presentation): Merge at //presentations/systemd-2016
I figured that adding old presentations in here might actually be a useful thing to do, no matter what format they're in.
This commit is contained in:
commit
10f9c4c208
16 changed files with 346 additions and 0 deletions
6
presentations/systemd-2016/.gitignore
vendored
Normal file
6
presentations/systemd-2016/.gitignore
vendored
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
slides.aux
|
||||||
|
slides.log
|
||||||
|
slides.nav
|
||||||
|
slides.out
|
||||||
|
slides.snm
|
||||||
|
slides.toc
|
1
presentations/systemd-2016/.skip-subtree
Normal file
1
presentations/systemd-2016/.skip-subtree
Normal file
|
@ -0,0 +1 @@
|
||||||
|
No Nix files will ever be under this tree ...
|
11
presentations/systemd-2016/Makefile
Normal file
11
presentations/systemd-2016/Makefile
Normal file
|
@ -0,0 +1,11 @@
|
||||||
|
all: slides.pdf
|
||||||
|
|
||||||
|
slides.toc:
|
||||||
|
lualatex slides.tex
|
||||||
|
|
||||||
|
slides.pdf: slides.toc
|
||||||
|
lualatex slides.tex
|
||||||
|
|
||||||
|
clean:
|
||||||
|
rm -f slides.aux slides.log slides.nav \
|
||||||
|
slides.out slides.toc slides.snm
|
6
presentations/systemd-2016/README.md
Normal file
6
presentations/systemd-2016/README.md
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
This repository contains the slides for my systemd presentation at Hackeriet.
|
||||||
|
|
||||||
|
Requires LaTeX, [beamer][] and the [metropolis][] theme.
|
||||||
|
|
||||||
|
[beamer]: http://mirror.hmc.edu/ctan/macros/latex/contrib/beamer/
|
||||||
|
[metropolis]: https://github.com/matze/mtheme
|
7
presentations/systemd-2016/demo/demo-error.service
Normal file
7
presentations/systemd-2016/demo/demo-error.service
Normal file
|
@ -0,0 +1,7 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Demonstrate failing units
|
||||||
|
OnFailure=demo-notify@%n.service
|
||||||
|
|
||||||
|
[Service]
|
||||||
|
Type=oneshot
|
||||||
|
ExecStart=/usr/bin/false
|
7
presentations/systemd-2016/demo/demo-limits.slice
Normal file
7
presentations/systemd-2016/demo/demo-limits.slice
Normal file
|
@ -0,0 +1,7 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Limited resources demo
|
||||||
|
DefaultDependencies=no
|
||||||
|
Before=slices.target
|
||||||
|
|
||||||
|
[Slice]
|
||||||
|
CPUQuota=10%
|
6
presentations/systemd-2016/demo/demo-notify@.service
Normal file
6
presentations/systemd-2016/demo/demo-notify@.service
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Demonstrate systemd templating by sending a notification
|
||||||
|
|
||||||
|
[Service]
|
||||||
|
Type=oneshot
|
||||||
|
ExecStart=/usr/bin/notify-send 'Systemd notification' '%i'
|
6
presentations/systemd-2016/demo/demo-path.path
Normal file
6
presentations/systemd-2016/demo/demo-path.path
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Demonstrate systemd path units
|
||||||
|
|
||||||
|
[Path]
|
||||||
|
DirectoryNotEmpty=/tmp/hackeriet
|
||||||
|
Unit=demo.service
|
6
presentations/systemd-2016/demo/demo-stress.service
Normal file
6
presentations/systemd-2016/demo/demo-stress.service
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Stress test CPU
|
||||||
|
|
||||||
|
[Service]
|
||||||
|
Slice=demo.slice
|
||||||
|
ExecStart=/usr/bin/stress -c 5
|
12
presentations/systemd-2016/demo/demo-timer.timer
Normal file
12
presentations/systemd-2016/demo/demo-timer.timer
Normal file
|
@ -0,0 +1,12 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Demonstrate systemd timers
|
||||||
|
|
||||||
|
[Timer]
|
||||||
|
OnActiveSec=2
|
||||||
|
OnUnitActiveSec=5
|
||||||
|
AccuracySec=5
|
||||||
|
Unit=demo.service
|
||||||
|
# OnCalendar=Thu,Fri 2016-*-1,5 11:12:13
|
||||||
|
|
||||||
|
[Install]
|
||||||
|
WantedBy=multi-user.target
|
6
presentations/systemd-2016/demo/demo.service
Normal file
6
presentations/systemd-2016/demo/demo.service
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
[Unit]
|
||||||
|
Description=Demo unit for systemd
|
||||||
|
|
||||||
|
[Service]
|
||||||
|
Type=oneshot
|
||||||
|
ExecStart=/usr/bin/echo "Systemd unit activated. Hello Hackeriet."
|
27
presentations/systemd-2016/demo/notes.md
Normal file
27
presentations/systemd-2016/demo/notes.md
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
# simple oneshot
|
||||||
|
|
||||||
|
Run `demo-notify@hello.service`
|
||||||
|
|
||||||
|
# simple timer
|
||||||
|
|
||||||
|
Run `demo-timer.timer`, show both
|
||||||
|
|
||||||
|
# enabling
|
||||||
|
|
||||||
|
Enable `demo-timer.timer`, go to symlink folder, disable
|
||||||
|
|
||||||
|
# OnError
|
||||||
|
|
||||||
|
Show & run `demo-error.service`
|
||||||
|
|
||||||
|
# cgroups demo
|
||||||
|
|
||||||
|
Start `demo-stress.service` without, show in htop, stop
|
||||||
|
Show slice unit, start slice unit
|
||||||
|
Add Slice=demo-limits.slice
|
||||||
|
daemon-reload
|
||||||
|
Start stress again
|
||||||
|
|
||||||
|
# Proper service
|
||||||
|
|
||||||
|
Look at nginx unit
|
BIN
presentations/systemd-2016/slides.pdf
Normal file
BIN
presentations/systemd-2016/slides.pdf
Normal file
Binary file not shown.
85
presentations/systemd-2016/slides.pdfpc
Normal file
85
presentations/systemd-2016/slides.pdfpc
Normal file
|
@ -0,0 +1,85 @@
|
||||||
|
[file]
|
||||||
|
slides.pdf
|
||||||
|
[notes]
|
||||||
|
### 1
|
||||||
|
### 2
|
||||||
|
Let's start off by looking at what an init system is, how they used to work and what systemd does different before we go into more systemd-specific details.
|
||||||
|
### 3
|
||||||
|
system processes that are started include for example FS mounts, network settings, powertop...
|
||||||
|
system services are long-running processes such as daemons, e.g. SSH, database or web servers, session managers, udev ...
|
||||||
|
|
||||||
|
orphans: Process whose parent has finished somehow, gets adopted by init system
|
||||||
|
-> when a process terminates its parent must call wait() to get its exit() code, if there is no init system adopting orphans the process would become a zombie
|
||||||
|
### 4
|
||||||
|
Before systemd there were simple init systems that just did the tasks listed on the previous slide.
|
||||||
|
Init scripts -> increased greatly in complexity over time, look at incomprehensible skeleton for Debian service init scripts
|
||||||
|
Runlevels -> things such as single-user mode, full multiuser mode, reboot, halt
|
||||||
|
|
||||||
|
Init will run all the scripts, but it will not do much more than print information on success/failure of started scripts
|
||||||
|
|
||||||
|
Init scripts run strictly sequential
|
||||||
|
|
||||||
|
Init is unaware of inter-service dependencies, expressed through prefixing scripts with numbers etc.
|
||||||
|
|
||||||
|
Init will not watch processes after system is booted -> crashing daemons will not automatically restart
|
||||||
|
### 5
|
||||||
|
### 6
|
||||||
|
How systemd came to be
|
||||||
|
|
||||||
|
Considering the lack of process monitoring, problematic things about init scripts -> legacy init systems have drawbacks
|
||||||
|
|
||||||
|
Apple had already built launchd, a more featured init system that monitored running processes, could automatically restart them and allowed for certain advanced features -> however it is awful to use and wrap your head around
|
||||||
|
|
||||||
|
Lennart Poettering of Pulseaudio fame and Kay Sievers decided to implement a new init system to address these problems, while taking certain clues from Apple's design
|
||||||
|
### 7
|
||||||
|
Systemd's design goals
|
||||||
|
### 8
|
||||||
|
No more init scripts with opaque effects -> services are clearly defined units
|
||||||
|
Unit dependencies -> systemd can figure out what can be started in parallel
|
||||||
|
Process supervision: Unit can be configured in many ways, e.g. always restart, only restart on success etc
|
||||||
|
Service logs: We'll talk more about this later
|
||||||
|
### 9
|
||||||
|
Units are the core component of systemd that users deal with. They define services and everything else that systemd needs to start and manage.
|
||||||
|
Note that all these are the names of the respective man page on a system with systemd installed
|
||||||
|
Types:
|
||||||
|
systemd.service - processes controlled by systemd
|
||||||
|
systemd.target - equivalent to "runlevels", grouping of units for synchronisation
|
||||||
|
systemd.timer - more powerful replacement of cron that starts other units
|
||||||
|
systemd.path - systemd equvialent of inotify, watches files/folders -> launches units
|
||||||
|
systemd.socket - expose local IPC or network sockets, launch units on connections
|
||||||
|
systemd.device - trigger units when certain devices are connected
|
||||||
|
systemd.mount - systemd equivalent of fstab entries
|
||||||
|
systemd.swap - like mount
|
||||||
|
systemd.slice - unit groups for resource management purposes
|
||||||
|
... and a few more specialised ones
|
||||||
|
### 10
|
||||||
|
Linux cgroups are a new resource management feature added quite a long time ago, but not used much.
|
||||||
|
Cgroups can be created manually and processes can be moved into them in order to control resource utilisation
|
||||||
|
Few people used them before systemd, limits.conf was often much easier but not as fine-grained
|
||||||
|
Systemd changed this
|
||||||
|
### 11
|
||||||
|
Systemd collects standard output and stderr from all processes into its journal system
|
||||||
|
they provide a tool for querying the log, for example grouping service logs together with correct timestamps, querying,
|
||||||
|
### 12
|
||||||
|
Systemd tooling, most important one is systemctl for general service management
|
||||||
|
journalctl is the query and management tool for journald
|
||||||
|
systemd-analyze is used for figuring out performance issues, for example by analysing the boot process, can make cool graphs of dependencies
|
||||||
|
systemd-cgtop is like top, but not on a process level - it's on a cgroup/slice level, shows combined usage of cgroups
|
||||||
|
systemd-cgls lists contents of systemd's cgroups to see which services are in what group
|
||||||
|
there also exist a bunch of others that we'll skip for now
|
||||||
|
### 13
|
||||||
|
### 14
|
||||||
|
### 15
|
||||||
|
Systemd criticism comes from many directions and usually focuses on a few points
|
||||||
|
feature-creep: systemd is absorbing a lot of different services
|
||||||
|
### 16
|
||||||
|
explain diagram a bit
|
||||||
|
### 17
|
||||||
|
opaque: as a result, systemd has a lot more internal complexity that people can't easily wrap your mind around. However I argue that unless you're using something like suckless' sinit with your own scripts, you probably have no idea what your init does today anyways
|
||||||
|
unstable: this was definitely true even in the first stable release, with the binary log format getting corrupted for example. I haven't personally experienced any trouble with it recently though.
|
||||||
|
Another thing is that services start depending on systemd when they shouldn't, a problem for the BSD world (who cares (hey christoph!))
|
||||||
|
### 18
|
||||||
|
Despite criticism, systemd was adopted rapidly by large portions of the Linux
|
||||||
|
Initially in RedHat, because Poettering and co work there and it was clear from the beginning that it would be there
|
||||||
|
ArchLinux (which I'm using) and a few others followed suit quite quickly
|
||||||
|
Eventually, the big Debian init system discussion - after a lot of flaming - led to Debian adopting it as well, which had a ripple effect for related distros such as Ubuntu which abandoned upstart for it.
|
160
presentations/systemd-2016/slides.tex
Normal file
160
presentations/systemd-2016/slides.tex
Normal file
|
@ -0,0 +1,160 @@
|
||||||
|
\documentclass[12pt]{beamer}
|
||||||
|
\usetheme{metropolis}
|
||||||
|
|
||||||
|
\newenvironment{code}{\ttfamily}{\par}
|
||||||
|
|
||||||
|
\title{systemd}
|
||||||
|
\subtitle{The standard Linux init system}
|
||||||
|
|
||||||
|
\begin{document}
|
||||||
|
\metroset{titleformat frame=smallcaps}
|
||||||
|
|
||||||
|
\maketitle
|
||||||
|
|
||||||
|
\section{Introduction}
|
||||||
|
|
||||||
|
\begin{frame}{What is an init system?}
|
||||||
|
An init system is the first userspace process (PID 1) started in a UNIX-like system. It handles:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Starting system processes and services to prepare the environment
|
||||||
|
\item Adopting and ``reaping'' orphaned processes
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Classical init systems}
|
||||||
|
Init systems before systemd - such as SysVinit - were very simple.
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Services and processes to run are organised into ``init scripts''
|
||||||
|
\item Scripts are linked to specific runlevels
|
||||||
|
\item Init system is configured to boot into a runlevel
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\section{systemd}
|
||||||
|
|
||||||
|
\begin{frame}{Can we do better?}
|
||||||
|
\begin{itemize}
|
||||||
|
\item ``legacy'' init systems have a lot of drawbacks
|
||||||
|
\item Apple is taking a different approach on OS X
|
||||||
|
\item Systemd project was founded to address these issues
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd design goals}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Expressing service dependencies
|
||||||
|
\item Monitoring service status
|
||||||
|
\item Enable parallel service startups
|
||||||
|
\item Ease of use
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd - the basics}
|
||||||
|
\begin{itemize}
|
||||||
|
\item No scripts are executed, only declarative units
|
||||||
|
\item Units have explicit dependencies
|
||||||
|
\item Processes are supervised
|
||||||
|
\item cgroups are utilised to apply resource limits
|
||||||
|
\item Service logs are managed and centrally queryable
|
||||||
|
\item Much more!
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd units}
|
||||||
|
Units specify how and what to start. Several types exist:
|
||||||
|
\begin{code}
|
||||||
|
\small
|
||||||
|
\begin{columns}[T,onlytextwidth]
|
||||||
|
\column{0.5\textwidth}
|
||||||
|
\begin{itemize}
|
||||||
|
\item systemd.service
|
||||||
|
\item systemd.target
|
||||||
|
\item systemd.timer
|
||||||
|
\item systemd.path
|
||||||
|
\item systemd.socket
|
||||||
|
\end{itemize}
|
||||||
|
\column{0.5\textwidth}
|
||||||
|
\begin{itemize}
|
||||||
|
\item systemd.device
|
||||||
|
\item systemd.mount
|
||||||
|
\item systemd.swap
|
||||||
|
\item systemd.slice
|
||||||
|
\end{itemize}
|
||||||
|
\end{columns}
|
||||||
|
\end{code}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
|
||||||
|
\begin{frame}{Resource management}
|
||||||
|
Systemd utilises Linux \texttt{cgroups} for resource management, specifically CPU, disk I/O and memory usage.
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Hierarchical setup of groups makes it easy to limit resources for a set of services
|
||||||
|
\item Units can be attached to a \texttt{systemd.slice} for controlling resources for a group of services
|
||||||
|
\item Resource limits can also be specified directly in the unit
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{journald}
|
||||||
|
Systemd comes with an integrated log management solution, replacing software such as \texttt{syslog-ng}.
|
||||||
|
\begin{itemize}
|
||||||
|
\item All process output is collected in the journal
|
||||||
|
\item \texttt{journalctl} tool provides many options for querying and tailing logs
|
||||||
|
\item Children of processes automatically log to the journal as well
|
||||||
|
\item \textbf{Caveat:} Hard to learn initially
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd tooling}
|
||||||
|
A variety of CLI-tools exist for managing systemd systems.
|
||||||
|
\begin{code}
|
||||||
|
\begin{itemize}
|
||||||
|
\item systemctl
|
||||||
|
\item journalctl
|
||||||
|
\item systemd-analyze
|
||||||
|
\item systemd-cgtop
|
||||||
|
\item systemd-cgls
|
||||||
|
\end{itemize}
|
||||||
|
\end{code}
|
||||||
|
|
||||||
|
Let's look at some of them.
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\section{Demo}
|
||||||
|
|
||||||
|
\section{Controversies}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd criticism}
|
||||||
|
Systemd has been heavily criticised, usually focusing around a few points:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Feature-creep: Systemd absorbs more and more other services
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd criticism}
|
||||||
|
\includegraphics[keepaspectratio=true,width=\textwidth]{systemdcomponents.png}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd criticism}
|
||||||
|
Systemd has been heavily criticised, usually focusing around a few points:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Feature-creep: Systemd absorbs more and more other services
|
||||||
|
\item Opaque: systemd's inner workings are harder to understand than old \texttt{init}
|
||||||
|
\item Unstable: development is quick and breakage happens
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}{Systemd adoption}
|
||||||
|
Systemd was initially adopted by RedHat (and related distributions).
|
||||||
|
|
||||||
|
It spread quickly to others, for example ArchLinux.
|
||||||
|
|
||||||
|
Debian and Ubuntu were the last major players who decided to adopt it, but not without drama.
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\section{Questions?}
|
||||||
|
|
||||||
|
\end{document}
|
BIN
presentations/systemd-2016/systemdcomponents.png
Normal file
BIN
presentations/systemd-2016/systemdcomponents.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 228 KiB |
Loading…
Reference in a new issue