Tragedy systemd

https://lwn.net/SubscriberLink/777595/a71362cc65b1c271/
  • Transfer
According to Wikipedia , tragedy is “a form of drama based on human suffering that causes catharsis or pleasure in the audience.” Benno Rice took inspiration from this definition in his speech at the 2019 linux.conf.au conference . His report is devoted to the history of systemd, in which a lot of suffering. And the audience really enjoyed it, so it all fits. Overall, this is a sympathetic and subtle look at one tumultuous chapter in the history of the Linux system.

Rice was also inspired by the article.Aurinnna Shaw on the so-called "culture of contempt." According to Shaw, people show contempt (for example, to developers who use another programming language) as a social sign, a way to show that they belong to the right group.

Of course, in this story there is such a culture: large groups together show a general contempt for systemd and for those who use this system. Hence the concept of change or resistance. Yes, familiar things are comfortable. But they are not necessarily good, especially if nothing has changed for many years.

The origins of the tragedy


According to Rice, the origin of systemd is related to the roots of the Unix system itself, which was a “happy coincidence” - a reaction to the external complexity of previous systems. Unix has been radically simplified in all respects, including loading user space. The subsystem initwas in charge of all the "housekeeping", including mounting file systems and running daemons. Although these are completely different tasks, they are combined into one process.

In those days there were few major demons: cron, update(whose job it is to sometimes write superblocks file system), and the process itself init. By the time 4BSD was released , Unix had the right demon getty, network daemons like routedand telnetd, as well as the “super-demon”inetd. It was here that the situation began to get interesting, but for a while it all worked quite well.

And then the Internet happened. Although he inetdcoped well with small volumes of traffic, he could not create a new process for each incoming connection. In the meantime, websites acquired databases and other systems while maintaining state between connections. The idea of ​​the demon shifted towards "service", and this is a completely different beast. The old initcould only start the service, but after that it became practically useless.

Part of the problem was the integration of services and configuration. Tasks such as mounting file systems belong to the latter; they are usually executed once at boot time, after which they are forgotten. But this approach is not enough for automated service management, which requires constant attention. This is how service oriented systems such as Upstart and systemd came into being. Here, Unix took the path blazed by other OSes. According to Rice, from the very beginning, Windows NT had a strong service model, and on Mac OS it still works in the form launchd. Other systems had to catch up.

Apple released launchdthe Tiger version, where it replaced a whole series of event-handling daemons, including init, cronandinetd. Thus, systemd became an attempt to borrow the good ideas implemented in launchd. When Lennart Pöttering began to solve this problem, he first looked in the direction of Upstart, an event-based system. She still worked on scripts, but Pöttering concluded that she could do better. In his article Rethinking PID 1, he calls launchd one of the samples for work. He thought about increasing the download speed and the need to set up the initialization system for hardware and software changes in a running system. During the creation of the initsystem were static, but the modern environment is much more dynamic than it was then.

Service level


Classic Unix-like systems are divided into two main components: the core and user space. But the cores over time became more dynamic and changeable, adapting to the equipment on which they work. This led to the need to create a new “service layer” between the core and user space. This layer includes components like udevNetwork Manager, but systemd aims to provide a comprehensive service level; this is why, over time, it absorbed the functionality of components such as udev. The process was quite successful and was accepted by most (but not all) Linux distributions, although it was often accompanied by sarcasm on the part of the community.

The same arguments often sound against the systemd demon: for example, that it violates the Unix philosophy. Rice assumes that this argument is based on the notion that systemd is a single monolithic binary file. In fact, systemd is structured differently: it’s a lot of separate binaries supported by a single project. As a “BSD man” (he was one of the main FreeBSD developers), Rice finds meaning in this combination of related concepts. Systemd is not at all a bloated and monolithic system, as some critics believe.

They say that in systemd a lot of bugs. “This is software,” of course, there will be bugs in it, Rice said. The notion that unlike any other systemd system should be perfect, raises the bar too high. At the very least, systemd almost always has a reasonable mode of operation in case of failure, he said.

In one form or another, one complaint is often repeated, which can be formulated as: “I can't stand Lennart Pöttering.” Rice refused to defend the Pöttering style of communication, but said that it’s impossible not to admire Pöttering’s willpower and determination. Not everyone can get through it all.

Systemd does not seek portability on systems other than Linux, which leads to a separate class of complaints. If systemd becomes the standard, there is a risk that operating systems outside of Linux will become even more isolated. Many want systemd to adhere to standard Unix interfaces, but Rice has a simple answer: “Unix is ​​dead”. Once Unix was an exercise in ultimate portability and was a real success. But now we are living “in the Linux world with small rounding errors” (which is painful for a FreeBSD person), and it makes no sense to stick to the classic Unix interfaces. The current situation is a “pathological monoculture” where Linux can dictate terms.

Systemd won a lot in this situation. For example, control groups are a highly efficient and interesting process control mechanism; without them, it would be much more difficult to solve these problems. They are much more powerful and detailed than FreeBSD jails. System developers like FreeBSD may see a threat in system intolerance. But this situation also gives them the opportunity to work freely and look for their own solutions to these problems.

Change and tragedy


Rice says that the systemd mission comes down to big destructive changes - this is where the tragedy begins. We have nerds have a complex attitude to change. Yes, it's amazing when we create them ourselves, but changes cannot be trusted if they come from outside. Systemd represents the kind of seemingly imposed change that people find threatening. People resist such changes even from pleasant developers, not to mention Pöttering, who doesn’t particularly sympathize with others. This leads to reflex reactions. But people need to retreat and think about what they are doing. “No one should threaten Lennart with death due to some kind of software,” Rice says. Contempt is not cool.

Instead, it's worth thinking: why did systemd appear at all and why is it important? What problem does he solve? For critics, one solution might be an attempt to create their own alternative: they will understand how fun this task is. Among other things, this story shows the difference in thinking in the new generation, which talks more about systems in terms of API and containers, for example.

So, what conclusions can be drawn from systemd history? One of the conclusions: you can not underestimate the transport of messages. Systemd makes extensive use of the D-Bus, which in many ways ensures its flexibility. Rice is not a D-Bus supporter, but a big supporter of inter-process messaging tires. At one time, he lobbied for the creation of such a native bus in BSD systems, preferably embedded in the core and with better security than the D-Bus. On top of this, you can make a proper remote procedure call system, where the kernel components and user space will run at the same level. In a properly designed system, the process will simply send an API request without worrying about where and how the request will be processed.

Among other lessons is the importance of maintaining a proper service life cycle without the need to install additional service management systems. It is important to adjust the automation of services through the API; and systemd provides a lot of it. Container support is also important: it is a useful way to encapsulate applications.

So, in modern Linux systems, systemd performs the role of a service layer. This is a good platform for managing services, but it should not be the only alternative. Systemd has a number of useful features, including convenient user units, consistent device naming, and even a good journaling model, Rice said. Binary magazines are a good thing as long as you have the tools to get information out of there. And systemd provides a new application model. Instead of a single binary file, an application becomes a bunch of modules in one container.

The world around us is changing, Rice said. We can either surrender to the flow or resist it. In the first case, it will probably be easier to swim than in the second. Rice suggested that those who criticize systemd study the system more closely and tried to find good things in it. Perhaps, then the catharsis phase of our tragedy will end - and we will be able to move on.

Video of the speech published on YouTube .


Also popular now: