Rethinking PID 1. Part 1

If you have good connections or you read well between the lines, you could already guess what this blog post is about. But nevertheless you can find this story interesting. So grab a cup of coffee, sit back, and read what's coming.

This is a long blog post, despite the fact that I would recommend you to read this long blog post, here's a one-line summarie: we are experimenting with a new download system and it's fun.

Here is the code . And here is the story:

Process ID 1

In each Unix system there is one process with a special identifier 1. It is started by the kernel before all subsequent processes, and it is also the parent process for all subsequent / remaining processes who could not find a parent. As a result, he can do a lot of things that other processes cannot afford. He is also responsible for some things for which other processes are not responsible, for example, for raising and supporting user space while the system is loading.
')
Historically in Linux, software acting as PID 1 was a highly respected sysvinit package, I think it has stayed in this field for too long. Replacements have been proposed many times, but only one of them was really accepted: Upstart, which has now found its way into many of the major distributions.

As mentioned, the main responsibility of the boot system is raising the user space (user environment). And a good boot system should do this quickly. Unfortunately, the traditional SysV boot system was not really fast.

Two things are important for fast and efficient loading:

• Run as little as possible
• And run as much as possible in parallel

What does it mean? Running less means starting a small number of services or postponing a launch until they are really needed. There are several services where we know that they will actually be requested sooner or later ( syslog , D-Bus , system bus , etc.), but for many others this is not important. For example, bluetoothd does not need to be started until a bluetooth dongle is plugged in or some application does not want to communicate with it via the D-Bus interface. The same applies to the printing subsystem: until the machine is physically connected to the printer, or some application wants to print something, there is no need to start a print daemon, such as CUPS . Avahi: if the machine is not connected to the network, there is no need to run Avahi , or until some application wants to use its API. And even take SSH : as long as nobody wants to connect to the machine, there is no need to start it, otherwise you can start it (SSH) when you first try to connect to the machine. (And note that on most machines where SSH can be started, most people connect to them only once every few months or even less often.)

Running as much as possible in parallel means that if we run something, we should not run it sequentially / one after another (as sysvinit does ), but run everything at the same time, so as to maximize the use of CPU and IO, and therefore the total system boot time will decrease.

Iron and software develop very dynamically

Modern systems (especially general-purpose systems) are very flexible in their configurations and use: they are mobile, start and stop various applications, add and remove various equipment, again and again. The boot system is responsible for maintaining services for listening to changes in hardware and software. The boot system must dynamically start (sometimes stop) services when they are needed to start a program or use some hardware.

Most of the current systems that are trying to parallelize the boot continue to synchronize the launch of the various daemons involved in the process: since Avahi needs the D-Bus , the D-Bus starts first and only when the D-Bus signals that it is ready. , Avahi will launch. Similarly for other services: libvirtd and X11 need HAL (taxes, here I mean Fedora 13 services, do not pay attention to the fact that HAL is no longer supported), therefore, HAL starts first, before libvirtd and X11 . Libvirtd, in turn, also needs Avahi , therefore it will also wait for Avahi to launch. And all these services, in turn, require syslog , which means they are all waiting until Syslog is fully initialized and running. And so on…

To be continued…