Systemd vs Init Cheatsheet for Linux

Systemd is the new init system, starting with Fedora and now adopted in many distributions like RedHat, Suse and Centos. Historically, most of us have been using traditional SysV init scripts normally residing in /etc/rc.d/init.d/. These scripts invoke a daemon binary which will then fork a background process. Even though shell scripts are very flexible, tasks like supervising processes and parallelized execution ordering are difficult to implement. With the introduction of systemd’s new-style daemons it is easier to supervise and control them at runtime and it simplifies their implementation.

The systemctl command is a very good initiative by the systemd team. It shows more detailed error messages and also runtime errors of services including start-up errors. systemd have introduced a new term called cgroups (control groups) which is basically groups of process that can be arranged in a hierarchy. With the original init system, determining which process does what and who it belongs to becomes increasingly difficult. With systemd, when processes spawn other processes these children are automatically made members of the parents cgroup thus avoiding confusions about inheritance.

systemd vs sysVinit cheatsheet

There are a lot of new systemd commands available on rhel / centos 7.0 version that would replace sysvinit commands. You can also download pdf version of the systemd vs sysvinit cheatsheet.

As requested by our fellow readers we have uploaded cheatsheet in A4 size - JPG version and PDF version.

27 Comments... add one

  1. Nice.

    A couple of typos:
    Journalctl –since=today
    journalctl shouldn't have a capital letter
    and the emdash (before 'since') should be dash dash

    Also, on more recent versions of systemd, you don't need the .service
    systemctl start dummy
    will work fine.

  2. I suppose a cheat sheet is less useful than a "filter" script that simply allows the sysVinit commands to do the systemctl thing. It would probably not even be as much time to write as to produce this cheat sheet, why not do that?

    if the length of a command is important, sysVinit wins ;-)
    (I'm sure there may be a bunch of reasons to still want systemd, but convincing traditionalists of the sysV world requires less typing, not more!)



    • This cheat sheet seems to be made for Fedora/RHEL (e.g. Debian doesn't store init scripts in /etc/rc.d/init.d/ and doesn't use chkconfig), so it could be different there. But it works mostly like that on Debian: I can still start/stop/restart/... services using the service-command. And telinit, runlevel, halt, poweroff, ... continue to work.

  3. reboot, poweroff, halt work just fine under systemd controlled machine.
    They all are symlinked by default to systemctl (just like halt and poweroff were symlinks to reboot on sysv init system).
    And also what is the difference between 'set multi-user target on next boot' (or any target) and 'change default runlevel'? One of them is redundant (former one IMHO)

    • "set multi-user target on next boot" only applies to the next boot, not any subsequent boots. "change default runlevel" applies to all subsequent boots, until a new default is set.

  4. Yes. Systemd is great system.
    It allow to hide rootkits and NSA services from users, and from root.
    It allow to filter inconvenient information from system logs.
    When it will be finished, it will control your firewall.
    And much much more.

    And everything of that to make life (of NSA agents, and crackers) easier.
    And you users, and administrators have to be happy with that, because life is easier.

    • Thanks. This is an excellent cheat sheet for those of us who are forced to use systemd. Systemd has only caused problems for me. I agree with "xx" - Systemd only help those who profit from obfuscation, or who want to make systems administration so difficult that it will become a specialty. Note that the commands in the Sys V column are short, so this fits on an A4 page, while the Systemd commands hog half the page. Systemd is bringing Windows level complication to our beloved Linux. Hopefully, it will go away - like KDE and AT&T Streams. I've started doing most of my development on Mac OS- it's a simpler system, and they don't fix what ain't broke.

  5. forgot to mention, that sysvinit uses easily editable shell scripts in /etc for config, while systemd uses binary modules somewhere in /lib/systemd/.

  6. Thanks for making this sheet, I hope it helps a lot of people :) Maybe you could add a little about the actual workings of systemd. I.E. Where you would typically find the service files (/etc/systemd/system/ and how you can have multiple profiles (thinking of netctl).

    As an Arch Linux user, I found the transition from sysVinit to systemd quite a chore. The sheer simplicity of the former is why it has been so loved even if systemd does bring a few advantages.

    My system refused to boot because of a single file (can't remember exactly which) not being present in the /etc/ folder; that same file (after creation) is always empty anyway...We've gone from a fail-safe environment to one that explodes on its' own, I could rant about persistant logs and that Linux is great because of the "Do one thing and do it well" mantra but, that's not useful.

    • Could you find out which file that was? The systemd guys are currently trying to make it possible to boot a system with nothing but /usr present, so it seems a bit weird that systemd itself needs an empty file in /etc. There are no empty files in /etc/systemd/ on Debian, so this problem could be Arch-specific.

      • Files in /etc/systemd are system configuration, whereas files in /usr/lib/systemd are static (should not change) configuration.

        If you want to add a service or modify the configuration of an existing service, you should either:
        1.) Create a new unit in /etc/systemd/system or /etc/systemd/user (depending on whether it's a user or system unit; generally it'll be a system unit), or
        2.) Copy the unit you want to modify from /usr/lib/systemd/ to /etc/systemd, then edit it to your liking.

        Then, if it's not already enabled, you should enable it using 'systemctl enable ' and start the service using 'systemctl start '. Otherwise, just restart it using 'systemctl restart '. ;)

        The reason for the two directories is to prevent changes you have made to services from being overwritten by OS updates (because they're in /etc/systemd), while still allowing the OS to update the service files in /usr/lib/systemd.

  7. While technically true, is it fair to claim Redhat, Fedora, and CentOS as separate distributions independently supporting systemd? This seems a bit like saying Ubuntu, Xubuntu, and Debian all support the Apt package management system.

  8. Hello,

    I've just encountered a new systemctl option, mask:

    systemctl mask sshd.service
    Masking a service prevents the service from being started manually or automatically. For this example, systemctl is creating a symlink from /etc/systemd/system/sshd.service to /dev/null. Targets in /etc/systemd override those provided by packages in /lib/systemd. systemd recognizes the symlink and will not start the service.

    There is no equivalent in SysVInit, correct?


Leave a Comment