54 lines
No EOL
3 KiB
Text
54 lines
No EOL
3 KiB
Text
[file]
|
|
slides.pdf
|
|
[notes]
|
|
### 1
|
|
### 2
|
|
Let's start off by looking at what an init system is, how they used to work and what systemd does different before we go into more systemd-specific details.
|
|
### 3
|
|
system processes that are started include for example FS mounts, network settings, powertop...
|
|
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
|
|
### 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
|
|
No more init scripts with opaque effects -> services are clearly defined units
|
|
Unit dependencies -> systemd can figure out what can be started in parallel
|
|
Process supervision: Unit can be configured in many ways, e.g. always restart, only restart on success etc
|
|
Service logs: We'll talk more about this later
|
|
### 9
|
|
Units are the core component of systemd that users deal with. They define services and everything else that systemd needs to start and manage.
|
|
Note that all these are the names of the respective man page on a system with systemd installed
|
|
Types:
|
|
systemd.service - processes controlled by systemd
|
|
systemd.target - equivalent to "runlevels", grouping of units for synchronisation
|
|
systemd.timer - more powerful replacement of cron that starts other units
|
|
systemd.path - systemd equvialent of inotify, watches files/folders -> launches units
|
|
systemd.socket - expose local IPC or network sockets, launch units on connections
|
|
systemd.device - trigger units when certain devices are connected
|
|
systemd.mount - systemd equivalent of fstab entries
|
|
systemd.swap - like mount
|
|
systemd.slice - unit groups for resource management purposes
|
|
... and a few more specialised ones |