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. Nevertheless, you may find this story interesting. So grab a cup of coffee, sit back and read what is coming.

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

Here is the code . And here is the story:

Process id 1

Each Unix system has one process with a special identifier 1. It is launched 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 during system boot.

Historically in Linux, software acting as PID 1 was a respected sysvinit package , I think it has remained in this field for too long. Substitutions have been proposed many times, but only one of them has really been accepted: Upstart, which has now found its way into many of the major distributions.

As mentioned, the primary responsibility of the boot system is to raise user space (user environment). And a good boot system should do it fast. Unfortunately, the traditional SysV boot system was not really fast.

Two things are important for a fast and efficient download:

• Run as much as possible less
• And how can run longer parallel

What does it mean? Starting less means starting a small number of services or delaying the 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 launched until the bluetooth dongle is plugged in or some application wants 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 the 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 no one wants to connect to the machine, there is no need to start it, otherwise you can start it (SSH) the first time you try to connect to the machine. (And note, on most machines where SSH can be started, most only connect to them 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 (how does sysvinit do it), but to start 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 are developing very dynamically

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

Most current systems that try to parallelize the boot continue to synchronize the launch of the various daemons involved in the process: since Avahi needs a D-Bus , the D-Bus starts first, and only when the D-Busgive a signal that it is ready, Avahi will start the launch. Similarly for other services: libvirtd and X11 need a HAL (dachshunds, 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 the launch of Avahi . And all these services in turn require syslog , which means they all wait until Syslog is fully initialized and started. Etc…

To be continued…