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