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