Add slides about classical init, systemd history

This commit is contained in:
Vincent Ambo 2016-01-20 17:52:42 +01:00
parent 0e0cb2ce25
commit f15a12bc4e
2 changed files with 53 additions and 7 deletions

View file

@ -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

View file

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