about summary refs log tree commit diff
path: root/presentations/systemd-2016/slides.tex
blob: c613cefd7ec4b9fdfe016fa6eed6a916de72745c (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
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}