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:
Vincent Ambo 2019-12-21 00:26:53 +00:00
commit 10f9c4c208
16 changed files with 346 additions and 0 deletions

6
presentations/systemd-2016/.gitignore vendored Normal file
View file

@ -0,0 +1,6 @@
slides.aux
slides.log
slides.nav
slides.out
slides.snm
slides.toc

View file

@ -0,0 +1 @@
No Nix files will ever be under this tree ...

View 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

View 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

View file

@ -0,0 +1,7 @@
[Unit]
Description=Demonstrate failing units
OnFailure=demo-notify@%n.service
[Service]
Type=oneshot
ExecStart=/usr/bin/false

View file

@ -0,0 +1,7 @@
[Unit]
Description=Limited resources demo
DefaultDependencies=no
Before=slices.target
[Slice]
CPUQuota=10%

View 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'

View file

@ -0,0 +1,6 @@
[Unit]
Description=Demonstrate systemd path units
[Path]
DirectoryNotEmpty=/tmp/hackeriet
Unit=demo.service

View file

@ -0,0 +1,6 @@
[Unit]
Description=Stress test CPU
[Service]
Slice=demo.slice
ExecStart=/usr/bin/stress -c 5

View 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

View file

@ -0,0 +1,6 @@
[Unit]
Description=Demo unit for systemd
[Service]
Type=oneshot
ExecStart=/usr/bin/echo "Systemd unit activated. Hello Hackeriet."

View 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

Binary file not shown.

View 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.

View 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}

Binary file not shown.

After

Width:  |  Height:  |  Size: 228 KiB