Systemctl

systemctl

Administratoren steuern Systemd über das Kommandozeilenprogramm "systemctl". Rufen Sie es ohne weitere Parameter auf, präsentiert es alle ihm bekannten Units (Bild 1).

Auf einem frisch gestarteten CentOS 7 mit grafischer Benutzeroberfläche sind das um die 130 Stück. Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken.

Alle Dienste präsentiert etwa "systemctl --type=service". Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige.

Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte. Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running").

In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit. Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot.

Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an (Bild 2).

In bestimmten Situationen erzeugt Systemd selbst eine Unit. Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes.

Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte. Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.

Änderungen nur mit root

Alle bisher vorgestellten Informationen darf jeder Nutzer abfragen. Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten.

Dann lassen sich einzelne Units über »systemctl start« aktivieren beziehungsweise mit »systemctl stop« anhalten. Der folgende Befehl fährt den SSH-Daemon hoch:

systemctl start sshd.service

Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen. Vergessen Sie im Unit-Namen den Typ, geht Systemd von ".service" aus.

Den SSH-Daemon könnten Sie folglich einfach mit »systemctl start sshd« anwerfen. "systemctl" wechselt natürlich auch Targets.

Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt:

systemctl isolate rescue.target

Die Angabe "isolate" sorgt dafür, dass ausschließlich die von "rescue.target" vorgegebenen Units aktiv sind, alle anderen Dienste und Units beendet Systemd.

Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn:

systemctl disable sshd.service

In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an:

systemctl enable sshd.service

Damit gehört der SSH-Daemon wieder zu allen Targets, die in seiner Unit-Datei (aus dem Listing "sshd.service") hinter "WantedBy" vermerkt sind.

Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen.

Datei:Bild1.png

Bild 2: In den Status-Informationen liefert "systemctl" unter anderem auch die PID (hier die 1270) und die Laufzeit des Dienstes (hier über eine Stunde).

Wichtige Systemd-Befehle im Überblick

systemctl
systemctl start sshd.service
systemctl stop sshd.service
systemctl disable sshd.service
systemctl enable sshd.service
systemctl --failed
systemctl isolate graphical.target
systemctl isolate multi-user.target
systemctl daemon-reload

Listing running services

$ systemctl UNIT LOAD ACTIVE SUB JOB DESCRIPTION accounts-daemon.service loaded active running Accounts Service atd.service loaded active running Job spooling tools avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running Bluetooth Manager colord-sane.service loaded active running Daemon for monitoring attached scanners and registering them with colord colord.service loaded active running Manage, Install and Generate Color Profiles crond.service loaded active running Command Scheduler cups.service loaded active running CUPS Printing Service dbus.service loaded active running D-Bus System Message Bus ...

Showing runtime status

$ systemctl status udisks2.service udisks2.service - Storage Daemon

         Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static)
         Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago
       Main PID: 615 (udisksd)
         CGroup: name=systemd:/system/udisks2.service
                 └ 615 /usr/lib/udisks2/udisksd --no-debug

Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus

Runlevel

What would get started?

… if I booted into a specific target?

If you want systemd to calculate the "initial" transaction it would execute on boot, try something like this:

$ systemd --test --system --unit=foobar.target

for a boot target foobar.target. Note that this is mostly a debugging tool that actually does a lot more than just calculate the initial transaction, so don't build scripts based on this.

Change current runlevel

In systemd runlevels are exposed via "target units". You can change them like this:

systemctl isolate runlevel5.target

Note however, that the concept of runlevels is a bit out of date, and it is usually nicer to use modern names for this. e.g.:

systemctl isolate graphical.target

This will only change the current runlevel, and has no effect on the next boot.

Change default runlevel

The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:

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

or

# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

Current runlevel

Note that there might be more than one target active at the same time. So the question regarding the runlevel might not always make sense. Here's how you would figure out all targets that are currently active:

$ systemctl list-units --type=target

If you are just interested in a single number, you can use the venerable runlevel command, but again, its output might be misleading.

Enable another getty

Simply instantiate a new getty service for the port of your choice (internally, this places another symlink for instantiating another serial getty in the getty.target.wants/ directory).

systemctl enable serial-getty@ttyS2.service
systemctl start serial-getty@ttyS2.service

Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in logind.conf(7). Also see this blog story.

Which service a process belongs to?

You may either use ps for that:

$ alias psc='ps xawf -eo pid,user,cgroup,args' $ psc ...

Or you can even check /proc/$PID/cgroup directly. Also see this blog story.

journalctl - display full messages

Even if less is not used?

A: Use:

journalctl --full

/tmp and tmpfs

My systemd system always comes up with /tmp as a tiny tmpfs. How do I get rid of this?

That's also a long story, please have a look on:* API File Systems (http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems)

cgroups

cgroup tree

$ systemd-cgls └ system

 ├ 1 /usr/lib/systemd/systemd --system --deserialize 18
 ├ ntpd.service
 │ └ 8471 /usr/sbin/ntpd -u ntp:ntp -g
 ├ upower.service
 │ └ 798 /usr/libexec/upowerd
 ├ wpa_supplicant.service
 │ └ 751 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
 ├ nfs-idmap.service
 │ └ 731 /usr/sbin/rpc.idmapd
 ├ nfs-rquotad.service
 │ └ 753 /usr/sbin/rpc.rquotad
 ├ nfs-mountd.service
 │ └ 732 /usr/sbin/rpc.mountd
 ├ nfs-lock.service
 │ └ 704 /sbin/rpc.statd
 ├ rpcbind.service
 │ └ 680 /sbin/rpcbind -w
 ├ postfix.service
 │ ├   859 /usr/libexec/postfix/master
 │ ├   877 qmgr -l -t fifo -u
 │ └ 32271 pickup -l -t fifo -u
 ├ colord-sane.service
 │ └ 647 /usr/libexec/colord-sane
 ├ udisks2.service
 │ └ 615 /usr/lib/udisks2/udisksd --no-debug
 ├ colord.service
 │ └ 607 /usr/libexec/colord
 ├ prefdm.service
 │ ├ 567 /usr/sbin/gdm-binary -nodaemon
 │ ├ 602 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
 │ ├ 612 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-O00GPA/database -seat seat0 -nolisten tcp
 │ └ 905 gdm-session-worker [pam/gdm-password]
 ├ systemd-ask-password-wall.service
 │ └ 645 /usr/bin/systemd-tty-ask-password-agent --wall
 ├ atd.service
 │ └ 544 /usr/sbin/atd -f
 ├ ksmtuned.service
 │ ├  548 /bin/bash /usr/sbin/ksmtuned
 │ └ 1092 sleep 60
 ├ dbus.service
 │ ├ 586 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
 │ ├ 601 /usr/libexec/polkit-1/polkitd --no-debug
 │ └ 657 /usr/sbin/modem-manager
 ├ cups.service
 │ └ 508 /usr/sbin/cupsd -f
 ├ avahi-daemon.service
 │ ├ 506 avahi-daemon: running [epsilon.local]
 │ └ 516 avahi-daemon: chroot helper
 ├ system-setup-keyboard.service
 │ └ 504 /usr/bin/system-setup-keyboard
 ├ accounts-daemon.service
 │ └ 502 /usr/libexec/accounts-daemon
 ├ systemd-logind.service
 │ └ 498 /usr/lib/systemd/systemd-logind
 ├ crond.service
 │ └ 486 /usr/sbin/crond -n
 ├ NetworkManager.service
 │ ├  484 /usr/sbin/NetworkManager --no-daemon
 │ └ 8437 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-903b6f6aa7a1-46c8-82a9-7f637dfbb3e4-wlan0.lease -cf /var/run/nm-d...
 ├ libvirtd.service
 │ ├ 480 /usr/sbin/libvirtd
 │ └ 571 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listenaddress 192.168.122.1 --dhcp-range 192.168.122.2,1...
 ├ bluetooth.service
 │ └ 479 /usr/sbin/bluetoothd -n
 ├ systemd-udev.service
 │ └ 287 /usr/lib/systemd/systemd-udevd
 └ systemd-journald.service
   └ 280 /usr/lib/systemd/systemd-journald

ps with cgroups

$ alias psc='ps xawf -eo pid,user,cgroup,args' $ psc

 PID USER     CGROUP                              COMMAND

...

   1 root     name=systemd:/systemd-1             /bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0
 415 root     name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
 928 root     name=systemd:/systemd-1/atd.service /usr/sbin/atd -f
 930 root     name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n
 932 root     name=systemd:/systemd-1/crond.service /usr/sbin/crond -n
 935 root     name=systemd:/systemd-1/auditd.service /sbin/auditd -n
 943 root     name=systemd:/systemd-1/auditd.service  \_ /sbin/audispd
 964 root     name=systemd:/systemd-1/auditd.service      \_ /usr/sbin/sedispatch
 937 root     name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f
 941 rpc      name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f
 944 root     name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4
 947 root     name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
 950 root     name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f
 955 dbus     name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
 969 root     name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6
 970 root     name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5
 971 root     name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1
 973 root     name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4
 974 root     name=systemd:/user/lennart/2        login -- lennart
1824 lennart  name=systemd:/user/lennart/2         \_ -bash
 975 root     name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3
 988 root     name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd
 994 rtkit    name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon

...