Add slides about classical init, systemd history
This commit is contained in:
parent
0e0cb2ce25
commit
f15a12bc4e
2 changed files with 53 additions and 7 deletions
26
slides.pdfpc
26
slides.pdfpc
|
@ -9,4 +9,28 @@ system processes that are started include for example FS mounts, network setting
|
|||
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
|
||||
-> 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
|
||||
|
|
34
slides.tex
34
slides.tex
|
@ -15,17 +15,39 @@
|
|||
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
|
||||
\item Adopting and ``reaping'' orphaned processes
|
||||
\item Starting system processes and services to prepare environment
|
||||
\item Adopting and ``reaping'' orphaned processes
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{What is systemd?}
|
||||
Bar baz
|
||||
\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}
|
||||
|
||||
\begin{frame}{Systemd units}
|
||||
Foo bar
|
||||
\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}
|
||||
|
||||
\section{Demo}
|
||||
|
|
Loading…
Reference in a new issue