systemctl steuert den Systemd

Beschreibung

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
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.

Installation

Syntax

Parameter

Optionen

Konfiguration

Anwendungen

Änderungen als root
- Alle 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.

[[Image:Bild1.png|top]]

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

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?

# 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

cgroups

Links

Dateien

Man-Pages

Intern

Weblinks

Kontrollfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5