Home Home > 2010 > 10 > 08 > systemd – and #osc10
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

systemd – and #osc10

October 8th, 2010 by

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.

8 Responses to “systemd – and #osc10”

  1. AlbertoP

    My two cents: it is “under heavy development”, “new”, and not exactly bringing amazing functionality in terms of end-user experience. So, just wait for “11.5” 😉

    • Tom Zöhner

      It’s an init system, of course it doesn’t bring great new end user experience, a new kernel version doesn’t either. It’s just a really cool piece of technology and better than what we currently use.

  2. Since systemd got dropped from Fedora 14, openSUSE 11.4 could be the very first major distro to ship it by default 🙂 It’s a really neat bit of engineering, and it sounds like Lennart and the rest of the team are really responsive to testing feedback and bug reports. I think getting it stable and performant by 11.4 will be easy with dev support.

  3. Rahul Sundaram

    Andrew,

    systemd was never dropped from Fedora 14. It is merely not the default.

  4. Anon

    My understanding is that systemd is less about only starting services on demand but rather solving the dependency issues by using blocking sockets.

    When it comes to booting quickly though, it’s less about starting everything in parallel and more about doing as little as possible. Sometimes tricks like prefetching also help as you can move stalls to more convenient locations. Arjan de Van loves talking about this stuff (e.g. http://permalink.gmane.org/gmane.comp.handhelds.meego.devel/5481 ).

    • Sean

      Arjan de Van’s analysis is interesting but he does set up a strawman argument that systemd inherently creates inefficient stalls. He asserts that systemd starts all services just-in-time which can be sub-optimal. However, systemd is perfectly capable of starting a service unconditionally at startup. Thus, with systemd you have a greater choice of strategies to employ to ensure that system resources are maximally employed on the most critical tasks.

  5. Andreas Jaeger

    Btw. there are more comments at: http://lwn.net/Articles/409304/

  6. Chris

    Good to know Linux is gaining upon Microsoft Windows 2000, after all these years…