diff options
| -rw-r--r-- | slides.pdfpc | 26 | ||||
| -rw-r--r-- | slides.tex | 34 |
2 files changed, 53 insertions, 7 deletions
diff --git a/slides.pdfpc b/slides.pdfpc index 2f6ac472edb5..c4b4bf5e9fc7 100644 --- a/slides.pdfpc +++ b/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 \ No newline at end of file +-> 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 diff --git a/slides.tex b/slides.tex index 5140c96dec13..8a5302726033 100644 --- a/slides.tex +++ b/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} |