Systemd is a replacement for SystemV init and in heavy development since the first announcement on April 30th by Lennart Poettering. Thanks to Kay Sievers’ work, we have packages for openSUSE curent Factory stream as well. I gave them a try a couple of weeks ago but somehow did not succeed with getting a working system. At LinuxKongress I met Lennart and decided to give systemd another try. I still could not log into the system due to it using NIS and automount for NFS home directories and started debugging this together with Kay over IRC in a virtual machine first. Once we had a workaround for me, I used systemd on my workstation and Kay and Lennart fixed the problem in systemd properly. I run into a couple of more problems and thus were fixed quickly so that the last release – systemd 11 – works fine on my workstation running openSUSE Factory (Factory is the development version for the next openSUSE release, in this case for 11.4).

The role of init, whether it’s SysV init, upstart or systemd, is to initialize the system (it’s the first process that gets started by the kernel) so that users can login, starts all the essential services, e.g. the cups daemon for printing, and handles session management. So, it’s a system and session manager.

So, what’s so cool about systemd?

The central idea is event based startup of services in such a way to “just wait until somebody tries to connect to the service and start it on demand” (quote from LWN). The traditional way is to start up everything in the right order at the beginning. Systemd uses socket and d-bus invocation: For socket invocation it just creates the socket and only starts the service once some other services connects to the socket. D-bus invocation is similiar: systemd hooks into d-bus and starts services if it sees requests for them. This kind of lazy startup of services only when needed is unique.

Systemd uses also some recent technology that was not available when SysV init was designed, e.g. d-bus. It especially uses cgroups (control groups) to track of processes that are started for a service. SysV init does this internally as well but with using cgroups in the kernel, systemd has an easier and more powerful way of controlling and tracking services.

Another thing is always fast boot time. openSUSE has done lots of improvements to the SysV init system with a parallel startup of services that we could not see any improvements with upstart when we tested it for openSUSE 11.3.

So, I compared boot time of both systemd and SysV init since right now systemd is an alternative to SysV init, and you can install both at the same time and use systemd with adding “init=/bin/systemd” on the kernel command line via grub. The startup with systemd felt faster, especially since the console getty process was there very fast. But gdm/kdm login is for me the end of booting and on my modern 4-way x86-64 system, this took a few seconds longer with systemd (just one test each, I have to do some real benchmarking with repeated runs later). So, I’m interested how this evolves over time and whether there’s anything that systemd can learn from Werner and how he tuned and improved the old SysV init system for openSUSE.

Finally, I welcome the work of developers of different distributions to work together on a common system. In the past – and even with LSB init scripts – every distribution needed to fix the supplied init scripts of packages or add ones. With systemd I see a convergence on init scripts so that they can be used by every distribution that runs systemd.

#osc10

#osc10 is the official hash tag for the openSUSE Conference 2010 on twitter – and #osc10 will have also a birds of a feather session on systemd, I invite you to discuss with Lennart and Kay systemd and how to get it running on your system/distribution.

Update 2010-10-10: It’s really #osc10, I used #osc2010 first which is wrong.

Systemd as default in openSUSE 11.4?

This is an option and the feedback of system testers and the way how the system developers handle the issues, will help us determine what to do.

If you like to install it now, read this article on the openSUSE wiki.

From my experience on a single system: It works fine and the feedback from Lennart and Kay is great. I’d like to see for now not a slow down in boot time and have to run a couple of measurements.

Screenshots of an init system

Systemd comes with some new commands, have a look at these:

$ systemctl

UNIT LOAD ACTIVE SUB JOB DESCRIPTION

dev-hugepages.automount loaded active running Huge Pages File System Automount Point

dev-mqueue.automount loaded active running POSIX Message Queue File System Automount Point

proc-sys...misc.automount loaded active waiting Arbitrary Executable File Formats File System Automo

sys-kern...ebug.automount loaded active running Debug File System Automount Point

sys-kern...rity.automount loaded active waiting Security File System Automount Point

[...]

ypbind.service loaded active running LSB: Start ypbind (necessary for a NIS client)

dbus.socket loaded active running D-Bus System Message Bus Socket

systemd-initctl.socket loaded active listening systemd /dev/initctl Compatibility Socket

systemd-logger.socket loaded active listening systemd Logging Socket

systemd-shutdownd.socket loaded active listening systemd Delayed Shutdown Socket

[…]

LOAD = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB = The low-level unit activation state, values depend on unit type.

JOB = Pending job for the unit.

283 units listed. Pass --all to see inactive units, too.

The use of cgroups can be shown nicely with systemd-cgls:

$ systemd-cgls

├ 2 [kthreadd]

├ [...]

├ user

│ ├ tux

│ │ └ no-session

│ └ aj

│ ├ 166

│ │ ├ 5456 sshd: aj [priv]

│ │ ├ 5462 sshd: aj@pts/1

│ │ └ 5464 -bash

│ ├ 161

│ │ ├ 4672 sshd: aj [priv]

│ │ ├ 4679 sshd: aj@pts/0

│ │ ├ 4682 -bash

│ │ └ 5652 systemd-cgls

│ └ no-session

│ ├ 558 /bin/bash

│ ├ 5016 SCREEN

│ └ 5062 /bin/bash

└ systemd-1

├ 1 /bin/systemd

├ sys-kernel-debug.mount

├ smartd.service

│ └ 3777 /usr/sbin/smartd

├ cron.service

│ └ 3767 /usr/sbin/cron

├ postfix.service

│ ├ 3742 /usr/lib/postfix/master

│ ├ 3761 qmgr -l -t fifo -u

│ └ 5289 pickup -l -t fifo -u

├ xdm.service

│ ├ 3611 /usr/bin/kdm

│ ├ 16029 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-8z7hEb

│ ├ 16030 -:0

│ ├ 16031 /usr/lib64/kde4/libexec/kdm_greet

│ ├ 16035 dbus-launch --autolaunch 67db9e8ea141a3bfcd29adf20000036b --binary-syntax --close-stderr

│ └ 16036 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

├ ntp.service

│ └ 3576 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf

├ autofs.service

│ └ 3631 /usr/sbin/automount -p /var/run/automount.pid

├ ypbind.service

│ └ 3316 /usr/sbin/ypbind

├ dbus.service

│ ├ 1183 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation

│ ├ 1254 /usr/lib/polkit-1/polkitd

│ ├ 12457 /usr/lib/udisks/udisks-daemon

│ └ 12464 udisks-daemon: polling /dev/sr0

├ home.mount

├ boot.mount

├ abuild.mount

├ dev-hugepages.mount

├ dev-mqueue.mount

├ udev.service

│ ├ 453 /sbin/udevd

│ ├ 597 /sbin/udevd

│ └ 2970 /sbin/udevd

├ var-run.mount

└ var-lock.mount

Both comments and pings are currently closed.