blob: 4d5447b6e54dc189993a707d0ba7b0d7f6fbd642 (
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
|
\documentclass[14pt]{beamer}
\usetheme{metropolis}
\newenvironment{code}{\ttfamily}{\par}
\title{systemd}
\subtitle{The standard Linux init system}
\begin{document}
\metroset{titleformat frame=allcaps}
\maketitle
\section{Introduction}
\begin{frame}{What is an init system?}
An init system is the first process (PID 1) started in a Unix like system. It handles:
\begin{itemize}
\item Starting system processes and services to prepare 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}
\section{Questions?}
\end{document}
|
