Systemd/systemctl tips and info

Vincent Danen

February 02, 2013

SysV-init has been a staple of Linux for years and years. In recent versions of Fedora (current version is 18) this has changed to using systemd. I'm no stranger to alternative means for running startup commands (I did, after all, have Annvix using Annvix:User_Guide/Services runit to handle boot with a custom script called srv to handle all the service management stuff (similar to service and chkconfig).

Now I need to learn a new system which is quite a bit different from both and reminds me a lot of launchd on OS X.

Command Comparison

Out of the box, we're used to commands like "service foo restart" or "chkconfig --add foo" and so forth. In Fedora 17, you could still use these commands and they would transparently go to the equivalent systemctl command. But some stuff doesn't work (like "chkconfig --list" doesn't really list the systemd service units), and it's just plain old better to learn the real commands for the day when these wrappers are deprecated.

SysV-init systemd What it does
chkconfig --list systemctl list-units -t service --all List available services; the systemctl command however does not list targets, so unlike chkconfig we do not know what runlevel (or boot target) a specific service will start in
chkconfig X on systemctl enable X.service Enables service X so that it will start at boot; this does not start X now
chkconfig X off systemctl disable X.service Disables service X so that it will not start at boot; this does not stop X now
service X start systemctl start X.service Starts service X immediately; service provides feedback on success, but systemctl does not (although it will tell you if it fails)
service X stop systemctl stop X.service Stops service X immediately
service X restart systemctl restart X.service Restarts service X immediately
service X status systemctl status X.service or
systemctl is-active X.service
Displays the status of service X; the first command displays the path to the loaded service unit file, the process, PID, etc. The second command will simply display whether or not the service is active (good for shell scripts, etc.)
chkconfig --list | grep '3:on' systemctl -p show "Wants" | cat Lists all services enabled for runlevel 3 (or multi-user/network/text);see #Systemctl_Show below.
telinit 3 systemctl isolate Switch to runlevel 3 (or See #Runlevels for more details.
chkconfig --list systemctl -t service Show all loaded services (running, failed, active, inactive, etc.). Can use target, etc. as well; no arguments shows everything loaded
n/a systemctl -t service | grep running Show all currently running services

Boot Commands

With systemd, if you want to boot into the non-default runlevel (or target) you need to edit the GRUB boot command for the linux kernel and options to specify the target to boot into. The default is typically You can do this by appending to the boot command:

linux /vmlinuz-3.7.2-204.fc18.i686.PAE root= [...] quiet

Other valid targets include "" (like runlevel 1), "" (like using init=/bin/sh). Further details can be found via man systemd.special.


SysV-init had the concept of runlevels, defined in /etc/inittab, for example:

# Default runlevel. The runlevels used are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)

The above will boot into runlevel 3 by default. Systemd does not have the same concept of runlevels, it uses targets instead. You can get the output of available targets using:

% systemctl list-units -t target --all
UNIT                         LOAD   ACTIVE   SUB    JOB DESCRIPTION             loaded inactive dead       Emergency Mode             loaded active   active     Graphical Interface            loaded active   active     Multi-User                loaded inactive dead       Rescue Mode              loaded inactive dead       Shutdown

I've snipped out the targets that are not really relevant as "runlevels" (for instance the "" isn't really a runlevel you would boot into, so I didn't include it in the above output). Again, if you want to see what any of these load, use systemctl show -p "Wants", which will show ou what services and/or targets this target (or runlevel) wants.

Also note that there is some correspondance with the initial runlevel; for instance can also be called as You can look at /lib/systemd/system/runlevel* to see which runlevel target corresponds to the systemctl target, for instance:

 ls /lib/systemd/system/ -al
lrwxrwxrwx. 1 root root 17 Jan  8 21:19 /lib/systemd/system/ ->

Changing the Default Runlevel

Changing the default runlevel is done by changing the symlink of the /etc/systemd/system/

% ls -al /etc/systemd/system/
lrwxrwxrwx. 1 root root 36 May 28  2012 /etc/systemd/system/ -> /lib/systemd/system/

So if you wanted to boot into runlevel3 ( by default, you would:

# cd /etc/systemd/system
# rm
# ln -s /lib/systemd/system/

Systemctl Commands In Depth

Here we'll look at a few commands in depth to try to make sense of them.

Systemctl Show

One of the more annoying things about systemctl is the show command. This is probably because it behaves quite differently from what I would expect from chkconfig and it's worth discussing in a little more depth.

The primary issue is that when you run systemctl show -p "Wants" it pipes it to less, so you don't really get to see all of the commands at once. Not sure why it does this, but it's annoying. Piping that output to cat instead gives us the whole thing together:

% systemctl show -p "Wants" | cat
Wants=systemd-update-utmp-runlevel.service sm-client.service abrt-vmcore.service abrt-xorg.service apcupsd.service sssd.service
mcelog.service nfs-idmap.service nfs-lock.service auditd.service crond.service sendmail.service sshd.service rsyslog.service acpid.service
avahi-daemon.service netatalk.service ntpd.service rpcbind.service NetworkManager.service chronyd.service httpd.service arp-ethers.service
atd.service irqbalance.service abrt-oops.service certmonger.service mysqld.service abrt-ccpp.service cups.path abrtd.service mdmonitor.service
plymouth-quit-wait.service systemd-logind.service dbus.service systemd-ask-password-wall.path plymouth-quit.service
systemd-user-sessions.service rc-local.service nrpe.service tcsd.service

This shows all the services and targets that the wants, which is our non-GUI runlevel (essentially runlevel 3). So if we want to see what starts with our graphical target:

% systemctl show -p "Wants" | cat
Wants=systemd-readahead-collect.service systemd-readahead-replay.service systemd-update-utmp-runlevel.service system-setup-keyboard.service
prefdm.service nrpe.service tcsd.service atieventsd.service

Based on the above, it doesn't look like the graphical target wants a whole heck of a lot. This is quite different from the chkconfig output where you see all the services and whether or not they are enabled in a particular runlevel. Here, at a quick glance, we would be thinking that things like dbus, getty, sshd, etc. aren't being started. But we need to look at the dependencies between targets to know for sure what is going on. To that end:

% systemctl show -p "RequiredBy"| cat


% systemctl show -p "Requires" | cat

So now we see that is required by (and likewise that requires This means that the must be loaded before can be loaded. In other words, for the we can add the "Wants" of to its "Wants" list. Confused yet? It's not bad, but just annoying. With systemctl you need to to run two commands ("Wants" on both targets) versus a simple chkconfig command (chkconfig --list | grep '5:on').


Here are links to other systemd documentation and articles worth reading: