Home Home > 2011 > 12 > 22 > Systemd-%E2%80%93-boot-faster-and-cleaner-with-opensuse-12-1
Sign up | Login

systemd – boot faster and cleaner with openSUSE 12.1

December 22nd, 2011 by

openSUSE 12.1 features systemd as a replacement for the System V init daemon. systemd provides a new and improved way of booting up your system and managing services. It comes with many new features like socket and dbus-activation, use of cgroups (control groups) and aggressive parallelization capabilities which leads to a faster boot-up of the system. Systemd also introduces a number of new features and tools for sysadmins. This article will explain what systemd does, how it does it and how to take advantage of the new possibilities it offers.

Booting your system and services

In openSUSE 12.1, systemd starts up and supervises openSUSE operating system and its services. This means a number of steps usually including the following:

  • mounting your disks (checking for errors if needed),
  • starting the firewall and other security tools,
  • starting services like mail, databases or web servers,
  • connecting the network and networked filesystems,
  • starting the graphical system and the login manager which brings you to your desktop

When up and running, systemd keeps tabs on the services and starts new ones (like printing) on demand, when they are needed.

Ye olde days (SysV init)

systemd replaces the old SysV init system, which is basically a loose collection of shell scripts in /etc/init.d (sometimes /etc/rc.d in other distributions). Those scripts would be called depending on the “runlevel” of the system, based on symbolic links to the scripts themselves in the /etc/init.d/rcX.d directories. Each directory there represented a runlevel number, with their order and interdependencies managed through the naming of symbolic links to those scripts, using numbers from 00 to 99. Upon booting, the system would go to a designated runlevel, starting all the scripts associated to that runlevel. While a bit brittle, this system was reasonably clear and understandable, although the scripts were usually quite big and complicated.

New and improved: systemd

Instead of shell scripts, systemd uses “.service” files that define various features provided by systemd, a bit like the old SysV init scripts but with an easier and more declarative syntax than bash.

Dependencies and events

Instead of starting the scripts based on a predefined number of runlevels, systemd uses dependencies and events to decide when to start a service. For example, once a network device is initialized, systemd starts the network service. Once a connection is made, network based services like NFS (Networked File Storage) and Samba (file sharing) can go ahead and start up. If there is no network, systemd won’t bother starting them. And without a printer attached to the system, printer service CUPS isn’t needed either.

systemd uses sockets and dbus for starting services and in this way allows on-demand starting of daemon processes, watching the sockets for requests from applications. For example, only when you try to print will the print service be started.

Starting and stopping services

systemd can start as many services as needed at the same time, respecting the dependencies and needs of the system. This, combined with the fact that it does not need to start a shell interpreter for each individual script, results in faster boot times.

Services in systemd can be disabled, enabled, started, stopped, restarted and reloaded just as the scripts in SysV but unlike SysV, the applications controlled by the script are closely monitored and controlled. Where SysV would not notice services going down (due to crashes for example) systemd will attempt to re-start them. And when systemd stops a process, you can be certain it has been stopped (thanks to using the cgroup kernel feature), whereas in SysV, processes sometimes managed to wrestle themselves out of control of the scripts.

Standardization

systemd strives towards standardizing init scripts which used to be different for each distributions. This should reduce the maintenance burden for distributions as they will share more work but it of course requires them to adapt to a common standard first. This means using the standard “systemctl” for controlling services instead of the /etc/rc* files. Currently, openSUSE still supports the rc-style files (providing symbolic links in /etc/rc.d ) so you can still run services by hand. systemd is also backwards compatible with the old-style init scripts which means that “non” standard (not included in systemd) scripts will keep working. For more details and a list of limitations in that regard please refer to here.

Using systemd

Let’s go over some features of systemd which are relevant for ‘normal’ users as well as system administrators.

Managing services and (auto)mounting devices

Devices marked via udev rules are marked as units in systemd and their udev properties can be used as configuration sources to set dependencies for device units. systemd also maintains mount and automount points and (un)mounts devices where needed. For every automount point we have a matching mount point. To let systemd automount a device, add “comment=systemd.automount” to an fstab line option, and the mountpoint is automatically handled as a automount point. This can be used for networked filesystems nfs and cifs. /etc/fstab is used as an extra configuration for these mount points. systemd also supports target units which are logically grouped and in turn these groups can be controlled together.

Stability and emergency features

Systemd automatically computes dependencies between services when running and is able to break dependencies cycles that is when a loop between services happen, systemd will break it once detected, your system will continue to work without user interaction. It also supports creating a snapshot and later restoring the system state and can be used in cases like emergency shell and provide an easy way of suspending services. However this feature is not persistent, and it is only kept in memory and is flushed after a reboot.

New System tools

A system adminstrator will welcome the new tools like systemctl to administrate the system. For example to check the status of the mysql.service, run:
$ systemctl status mysql.service
mysql.service - LSB: Start the MySQL database server
Loaded: loaded (/etc/init.d/mysql)
Active: active (running) since Wed, 02 Nov 2011 10:53:34 +0100; 24h ago
Process: 3242 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/mysql.service
├ 3578 /bin/sh /usr/bin/mysqld_safe --mysqld=mysqld --user=mysql --pid-file=/var/run/mysql/mysqld.pid --socket=/var/ru...
└ 4191 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --lo...

What is really cool with systemctl is its tab completion. on first level for command like systemctl will show you wich action you are able to run. On second level it will show which service name you can use like systemctl start my will complete to mysql.service

Disable/Enable a service

 systemctl disable mysql.service
 systemctl enable mysql.service

Note that chkconfig is systemd aware and will show you when a service is systemd native or not.

Locations
systemd service files are mainly stored in /lib/systemd/system

Start stop your computer
 systemctl reboot
 systemctl halt
 systemctl poweroff
 systemctl emergency
 systemctl rescue

Get informed

 systemd-analyse --time: give your boot time of your system
 systemd-analyse --blame: find which service took too much time to boot
 systemd-analyse --plot > bootchart.svg : see your boot, in a graphical chart
 systemctl dot : Use a command line like systemctl dot --order | dot -Tsvg > systemd-order.svg to generate a graphical dependency tree

Debug
You can activate a debug mode on startup by adding on the boot line:

 systemd.log_target=kmsg systemd.log_level=debug

Moving backwards

While we do not recommend anyone using sys V init on 12.1, people who wish to choose it as the default can do so by installing sysvinit-init package (it will uninstall systemd-sysvinit package) or changing their grub options. Even if you don’t use systemd, don’t try to uninstall its package, it might break your system. You don’t need to remove systemd-sysvinit in case of emergency, if you let installed the sysvinit package you can boot with traditonnal init by adding on your boot line init=/sbin/sysvinit et voilà !

Both comments and pings are currently closed.

44 Responses to “systemd – boot faster and cleaner with openSUSE 12.1”

  1. Argoson

    Shouldn’t the command be ‘systemd-analyze’ ? you wrote ‘systemd-analyse’

    • Henrik Pauli

      Well, ‘analyse’ is the non-US spelling of ‘analyze’.

      • Bobby

        Analyse is the correctly spelled English word but I am not sure if it would work as a command because Linux speaks American English.

        • Kaacz

          wel .. command is systemd-analyze .. and params not have “–”

          right is “systemd-analyze time” and “systemd-analyze blame” .. “systemd-analyze plot”.

          “systemd-analyze –help” :-)

  2. Staffan Tj

    Under SysV init processing, you could make sure unwanted services (eg X) did not start by staying in the relevant runlevel. How does that translate to systemd if systemd starts any service when needed? What if I don’t want an X server started if someone asks for one (but I want it available if I want to switch the system to that mode)?

    • Oh man…I had fun with that. I wound up using YaST to get myself to runlevel 3, but I want a config file way to do this. (That’s why I’m replying, in hopes of getting the answer as well.)

      • This is the easiest version to switch to runlevel 3:
        Bash:
        Open a terminal.

        You will see for example: MRebhan@GRINS-xD:~>
        Type in: su
        You will see: Passwort:
        Type in your password.
        If it is correct, you will see: GRINS-xD:/home/MRebhan # (in red)
        Type in: init 3 (For Runlevel 3)
        If it isn’t correct, it will show this:
        su: ungültiges Kennwort
        MRebhan@GRINS-xD:~>
        Try it again.
        Or:
        Open a terminal.

        You will see for example: MRebhan@GRINS-xD:~>
        Type in: su -c “init 3″
        You will see: Passwort:
        Type in your password.
        If it is correct, it switches to Runlevel 3.
        If it isn’t correct, it will show this:
        su: ungültiges Kennwort
        MRebhan@GRINS-xD:~>
        Try it again.

        ——————————————————————————————–

        But I measured the boot time and there was SysVInit THREE TIMES faster than systemd…

        ——————————————————————————————–

        • Bobby

          I also have the feeling that SysV with it’s init process was a lot faster than Systemd.
          I don’t know how that can be possible since the processes start parallel but my system boots a lot slower than it used to with openSuse 11.4.

          I am not at all impressed by OS 12.1 not only because of this but more because of KMail2! Skype (microphone not working no matter what I do) and Digikam. Nothing that I need badly seems to be working after a fresh install of openSuse 12.1.
          I am planning to either downgrade to 11.4 or switch distro.

    • Cristian Rodriguez

      Doh.

      ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

      that’s all you need (also reading the manual certainly helps)

  3. I’ve switched back to upstart\sysvinit on my 12.1 and I’m concerned of how well it works for all of the current servers that use init.d.

    As an example, I just reinstalled a older version of Fedora 14, from Fedora 16, because slapd (openLDAP) failed to work.

    I’ll force myself to use it, once it becomes more mature and has MUCH MORE documentation. Until then, I hope that openSuSE continues to provide support for sysvinit.

  4. Carl

    Is this a contradiction

    (a) installing sysvinit-init package (it will uninstall systemd-sysvinit package)

    (b) Even if you don’t use systemd, don’t try to uninstall its package, it might break your system.

  5. Joseph

    The title of this article is “systemd – boot faster and cleaner with openSUSE 12.1″. Would anyone from OpenSUSE care to address Phoronix’s benchmark that should no perceptible change in boot speed between a default install of 11.4 and 12.1?

    • Cristian Rodriguez

      Phoronix benchmarks are non-sense, meaningless stuff, do not take them seriously.

      • Joseph

        That’s not a convincing refutation. We’re not talking anything more complex that a boot and a stopwatch. Are you suggesting that if I install each to either bare metal or a VM this weekend and time them I’m going to see a significant time savings? No other review so far has reported noticing any appreciable difference either.

      • lundgren

        “They are stupid” does little to bolster your argument. Where are the benchmarks that show that it is faster?

    • Diederik

      If they upgraded openSUSE, they would still be using sysvinit. :p
      Really, Phoronix’s tests include random combination of drivers/hardware and distributions where you can’t tell which component really caused it. Yet they claim a hard verdict that people believe.

      My laptop starts up really fast nowadays. With the `systemd-analyze plot > boot.svg` command it is visible that it:
      a) only takes 11 seconds (and X is already loaded sooner)
      b) many services are started in parallel, such as MySQL and PostgreSQL which both take 4 seconds alone.

      Really, sysvinit could never provide this.

  6. JAG

    systemd is terrible. Hanging my network on boot. Can’t track it down. Please revert back.

  7. suseuser

    systemd? no way.

  8. ZaWertun

    systemd-analyse –time -> systemd-analyze time
    systemd-analyse –blame -> systemd-analyze blame
    systemd-analyse –plot -> systemd-analyze plot

  9. Shyukri

    I did a zypper dup from 11.4 and systemd hangs on boot- stopping at network services or fsck.

    • Joseph

      Is this on a laptop or desktop? People who observed it on a laptop needed to physically connect the system to the internet (or boot with sysvinit) because systemd was hanging looking for a network connection. If you check the forum, there might be a new systemd package that fixes this, but hasn’t been released as an update, if I recall correctly. You are definitely not alone in this problem.

  10. anon

    Seems this is not well implemented in opensuse 12.1, yet. Take the crypto service:

    # systemctl status crypto.service
    crypto.service
    Loaded: masked (/dev/null)
    Active: inactive (dead)

    # systemctl disable crypto.service
    Failed to issue method call: No such file or directory

    # systemctl enable crypto.service
    Failed to issue method call: No such file or directory

    Ok then, let’s do it old style:

    # insserv -r boot.crypto
    insserv: Note: sysvinit service boot.crypto is shadowed by systemd crypto.service,
    Forwarding request to ‘/bin/systemctl disable crypto.service’.
    Failed to issue method call: No such file or directory
    insserv: Forward service request to systemctl returned error status : 256

    Basically, nothing works.

    • Cristian Rodriguez

      You are doing it wrong, crypto service is handled different, with an specialized tool called systemd-cryptsetup hence boot.crypto is masked.

  11. Roman Bysh

    There are too many users that are uninformed about systemd.
    This is why we’re getting these types of responses.

    We really need more information posted on opensuse.org in 2012.

    A teach video from openSUSE would be welcome.

  12. Rob

    I’ve been reading up on systemd a bit
    Also been using it a bit and it does have it’s rough edges.

    But try not to judge it if it doesn’t feel as comfy as the good old sysV init scripts.
    Give it some time, a lot of people spend a lot of time on this and they did make a lot of improvements compared to sysv, once you get the hang of systemd you’ll find it easy to use.

    Documentation is indeed plenty available although it’s more for devs than admins so it’s a bit annoying to read if you just want to do something.

    Here you can find documentation and manuals on systemd
    http://www.freedesktop.org/wiki/Software/systemd

    If you scroll down a bit you find a nice blog aimed ad sysadmins and users.
    Excellent for getting you feet wet with systemd

    Most of the tips and tricks/man pages/faq started to make more sense after I read this blog
    http://0pointer.de/blog/projects/systemd-for-admins-1.html
    page 2 is :
    http://0pointer.de/blog/projects/systemd-for-admins-2.html
    I think you can manage the others by yourselves

    Just a few annoyances I’ve had with 12.1 and the workarounds I found so far :

    I’ve found that turning on ipv6 and/or switching to network manager if your situation allows that helps to solve a lot of issues with network.

    There has been a note on crypt drives in the suse release notes
    (these things have been written for a reason ppl, read them before you start b#$%@ing)
    read them on your local file system here:
    file:///usr/share/doc/release-notes/openSUSE/RELEASE-NOTES.en.html

    Ok if you like to dig a bit more try digging on bugzilla for issues
    bugzila.opensuse.org it does help, and you can help suse to by posting bugs there

    sftp failed for me until I read in the bugzilla that the path to the sftp binary is incorect in /etc/sshd/sshd_config

  13. JAG

    OK, I’m done. There are entire package libraries missing for simple things like Wine.
    The system is unstable, and that only happens on linux when the network is puking. I’m going back to 11.4. This is all suck and no blow.

    • Tim

      If you’re missing package libraries there’s most likely something wrong with your repositories config, nothing to do with systemd. I have wine working here fine on 64-bit 12.1 (and yes the machine uses systemd :))

  14. Good article, we definitely need to get the work out on this. My initial upgrade from 11.4 to 12.1 more than DOUBLED my boot time. Eventually I learned about systemd-analyze and went in and did some surgery. Now I’m on par with the boot times I had under 11.4.

    • Joseph

      Johnm, so what you’re saying is that you had to do a lot of work yourself and eventually managed to achieve… boot times no better than you had before? Systemd should have been left out of OpenSUSE until OpenSUSE was ready to fully take advantage of it. That’s what the community statement so much work was put into made clear: OpenSUSE values stability over features. This time, though, between systemd and KMail2, it seems we used the Fedora community statement, “features over stability”, or at least Ubuntu’s, “just stick it in there now and we’ll get it working in a release or two”.

      • Yeah pretty much. And I agree with you, putting systemd in 12.1 was premature.

        But.. i’m not complaining. As I learn more about it i’m starting to see the long term value. Its more tidy and logical then just having a bunch of shell scripts. Yet it’s still easy to tweak.

        IMHO

  15. Henrik Pauli

    Curious… Ubuntu and its brethren have switched to Upstart, which aims to provide a very similar framework itself…

    Why systemd? Is this a case of Not Invented Here, or was there some feature that the Upstart crew was unwilling to add to it, or just why bother making yet another service manager?

    • Bobby

      I am not an Ubuntu user but I tried the latest version recently and I have to say that the openSuse developers should look into Ubuntu’s code so they can see what makes a Linux system fast!
      And although I love KDE I have to say that the KDE devs should look into Gnome’s code to see what makes a DE and it’s applications start up fast. Until then they shouldn’t release another version of openSuse.

    • TDU

      Upstart is merely a stopgap. There’s no cgroup handling, no socket-based activation, that alone makes systemd worth its own existence.

  16. anon

    Why does rcapparmor redirect to boot.apparmor.service which seems not to exist?

    # rcapparmor status
    redirecting to systemctl
    boot.apparmor.service
    Loaded: error (Reason: No such file or directory)
    Active: inactive (dead)

    And why does the following command work even though apparmor.service exists nowhere
    on my filesystem?

    # systemctl status apparmor.service
    apparmor.service – LSB: AppArmor initialization
    Loaded: loaded (/etc/init.d/boot.apparmor)
    Active: active (exited) since Thu, 29 Dec 2011 12:10:32 +0000; 2h 21min ago
    Process: 932 ExecStart=/etc/init.d/boot.apparmor start (code=exited, status=0/SUCCESS)
    CGroup: name=systemd:/system/apparmor.service

  17. Bobby

    After testing openSuse 12.1 for weeks now on both my Laptop and PC I have to sadly conclude that it’s my worse update in years.
    I tried to fix so many things until I just got frustrated and went back to 11.4 starting with the laptop today. It’s now smooth sailing with 11.4.
    The PC will follow tomorrow.

  18. Bobby

    I have a suggestion. Maybe the openSuse team should try and get rid of the rough edges in 12.1 and release a remaster version. I would give it another shot in that case.
    I love openSuse very much but I am really disappointed with 12.1.

  19. Andreas

    Hi, wondering why my system bootup takes a long time I used the following command to see the reason:

    r-andreas:~ # systemd-analyze blame
    23023ms nfs.service

    Can anybody explain to me why the mounting of my /home from a fast NFS-server takes sooooo long? 23s is more than I ever had with previous versions from openSUSE!

    • Deanjo

      Ya NFS is horribly broken in 12.1. The reason it takes so long is that it is trying to mount the share before the service is started.

  20. Just a comment for the defenders of the systemd. Some people just want to use their computer for other things than setting/tweaking/tuning the system all day long.
    Really OpenSUSE used to be my distro of choice for the fact that it let me (most of the time) use the system without any hassle. Now I’m just losing too much time making it work… that’s a little of a turn off for me …
    Maybe I should try Ubuntu instead.

  21. ElevenYearsSuSE

    Hi,
    After upgrading our mailserver to openSUSE 12.1:
    - syslog (with syslog-ng) dont’t start anymore.
    - The only way to stop spamd is to kill it. systemctl stop spamd.service doesn’ work at all.
    - The only way to disable mysql is to chmod 000 /etc/init.d/mysql. AND it is not possible to deinstall mysql without installing an other DB that the system doesn’t need or break the dependencies.
    In April I will try Ubuntu Server LTS for all our Server! 5 years support instead of 1,5 years with openSUSE now”
    I really liked SuSE but now it seem to be the time to go…