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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
[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
### 10
Linux cgroups are a new resource management feature added quite a long time ago, but not used much.
Cgroups can be created manually and processes can be moved into them in order to control resource utilisation
Few people used them before systemd, limits.conf was often much easier but not as fine-grained
Systemd changed this
### 11
Systemd collects standard output and stderr from all processes into its journal system
they provide a tool for querying the log, for example grouping service logs together with correct timestamps, querying,
### 12
Systemd tooling, most important one is systemctl for general service management
journalctl is the query and management tool for journald
systemd-analyze is used for figuring out performance issues, for example by analysing the boot process, can make cool graphs of dependencies
systemd-cgtop is like top, but not on a process level - it's on a cgroup/slice level, shows combined usage of cgroups
systemd-cgls lists contents of systemd's cgroups to see which services are in what group
there also exist a bunch of others that we'll skip for now
### 13
### 14
### 15
Systemd criticism comes from many directions and usually focuses on a few points
feature-creep: systemd is absorbing a lot of different services
### 16
explain diagram a bit
### 17
opaque: as a result, systemd has a lot more internal complexity that people can't easily wrap your mind around. However I argue that unless you're using something like suckless' sinit with your own scripts, you probably have no idea what your init does today anyways
unstable: this was definitely true even in the first stable release, with the binary log format getting corrupted for example. I haven't personally experienced any trouble with it recently though.
Another thing is that services start depending on systemd when they shouldn't, a problem for the BSD world (who cares (hey christoph!))
### 18
Despite criticism, systemd was adopted rapidly by large portions of the Linux
Initially in RedHat, because Poettering and co work there and it was clear from the beginning that it would be there
ArchLinux (which I'm using) and a few others followed suit quite quickly
Eventually, the big Debian init system discussion - after a lot of flaming - led to Debian adopting it as well, which had a ripple effect for related distros such as Ubuntu which abandoned upstart for it.
|
