[systemd] design notes

Reference:
http://www.0pointer.de/blog/projects/systemd.html

For a fast and efficient boot-up two things are crucial

• To start less.
• And to start more in parallel.

Parallelizing Socket Services

• Wouldn't it be great if we could get rid of the synchronization and serialization cost?
• What are we waiting?
• they wait until the socket the other daemon offers its services on is ready for connections.
• Solution
• create the listening sockets before we actually start the daemon.
• and then just pass the socket during exec() to it. That way, we can create all sockets for
• all daemons in one step in the init system, and then in a second step run all daemons at once.
• If a service needs another, and it is not fully started up, that's completely OK:
• what will happen is that the connection is queued in the providing service and the client will potentially block on that single request.
• But only that one client will block and only on that one request.
• Basically, the kernel socket buffers help us to maximize parallelization, and the ordering and synchronization is done by the kernel, without any further management from userspace

AF_UNIX

• A good init system should start only what is needed, and that on-demand.
• Either lazily or parallelized and in advance.
• However it should not start more than necessary, particularly not everything installed that could use that service.

• How can we keep track of processes, so that they cannot escape the babysitter, and that we can control them as one unit even if they fork a gazillion times?
• Solution:
• Control Groups (aka "cgroups").

 

System should have

1.
service: these are the most obvious kind of unit: daemons that can be started, stopped, restarted, reloaded.

2.
socket: this unit encapsulates a socket in the file-system or on the Internet.