| No Comments | No TrackBacks
Lennart Poettering talked about systemd, which is a replacement for the sys-v init.d scripts (which start software on Linux computers when you boot up). systemd is a system and session manager for Linux. It looks after login sessions. systemd is compatible with sysV and LSB init scripts. It can use paralleilzation of service starts up. It uses socket and D-Bus actifavation for starting services. Can do on-demand starting of daemons. Uses CGroups to track processes. Can snapshot and restore system state. Maintains mount and automount points. Can look after services considering dependancies, and does transactions. (All of that is a re-phrasing of the short description they provide on their website).

The kernel starts one process when it boots up. This is process is init. sysv is an init process. Process 1 is special. All other programs are children of the init process. If the init process dies the kernel throws a kernel fault.

In systemd everything is started in parallel, despite the interesting feature that (for the example given) d-bus depends on syslog, and avahi and bluetooth both depends on syslog and d-bus. Apple solved this in their launchd approach by ripping out the socket binding of all the daemons (ie the syslog socket and the dbus daemon) and binds them on behalf the daemons. This is called socket activation. When the init process detects that something tries to connect to a socket you then start the daemon.

This is actually not a new idea. The inetd has been doing 'start on connection' type of work for awhile. So some daemons don't need to be modified to work with systemd. Someone asked if you can use LD_PRELOAD to trick proprietary software (that you can't patch), but apparently it's really tricky, and the systemd people haven't done that.

systemd can automatically restart services that crash. Not only that, but it will get the same socket back again, and so it will not drop lots of connections because systemd kept a duplicate of the socket, so those client connections haven't been dropped.

systemd can also do bus-based activation. So systemd adds some bus names (or whatever it's called) for the services onto the bus. Then when something asks the bus for that bus name, systemd starts up the service to satisfy the request. They also use hardware based activation (like when a network interface comes up) to start things. By default they don't shut down services when hardware things go away.

They extend this idea of when-needed-start-service to file systems, to parallelize file system jobs. This is used for mounting sysfs, the filesystem for binfmt. 

in systemd they try to avoid shell programming, because shell programming is quite slow, because you do lots of forking as you run grep, awk, cp, mv, etc commands. In systemd they don't want to use the shell in the boot process. Often the init.d shell scripts are all the same. The have a case statement, they pick some configuration files. In the programming world when you have template code you try to avoid that by refactoring it out, so that is what they did.

Of course there are other things like setting the hostname, or doing modprobe, or starting udev, or removing a .pid file if it already exists. And systemd does that. They have also built in 'proper' debugging facilities. For instance they put in tracing, graphical dependencies, and an interactive bootup.

systemd is meant to be a good babysitter. They use control groups to supervise services. Control groups allow you to group processes into a hierarchical tree. Control Groups were originally about managing resources. However the implementation is abstract, so systemd can use this.

No TrackBacks

TrackBack URL:

Leave a comment

About this Entry

This page contains a single entry by Geoff Crompton published on January 26, 2011 3:27 PM.

node.js was the previous entry in this blog.

latest and coolest html5 media is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.



Powered by Movable Type 4.23-en