2e3b03b5ae
Change-Id: I72b25680e7167c3a55477111c28b1d4936c60e2c Reviewed-on: https://cl.tvl.fyi/c/depot/+/606 Reviewed-by: tazjin <mail@tazj.in>
85 lines
No EOL
5.3 KiB
Text
85 lines
No EOL
5.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
|
|
### 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. |