Übersicht für systemctl

• Liste mit Diensten, die Probleme haben: systemctl --failed
• Start/Stop/Restart a service: systemctl start|stop|restart xyz.service …
• Restart a service, only if it's running: systemctl try-restart xyz.service …
• Enable/Disable a service for start on boot-up: systemctl enable|disable xyz.service …
• Status des Systems: systemctl status
• Status eines Dienstes: systemctl status xyz.service
• Konfiguration eines Dienstes mit override.conf anpassen: systemctl edit getty@tty1.service
• Konfiguration eines Dienstes bearbeiten: systemctl edit --full getty@tty1.service
• View config of a service: systemctl cat getty@tty1.service
• Eine bestimmte Einstellung anzeigen: systemctl show --property=After default.target
• Revert override.conf: systemctl revert xyz.service
• Logging-Level für systemd anpassen: systemd-analyze log-level debug (Logmeldungen finden sich auch in dmesg)
• Status von systemd ausgeben: systemd-analyze dump
• Abhängigkeiten auflisten, Units die zuvor gestartet werden müssen: systemctl list-dependencies …

https://wiki.archlinux.org/index.php/Systemd

Übersicht für journalctl

• Logmeldungen nach Priorität filtern: journalctl -p err|warning
• Logmeldungen nach Dienstname filtern: journalctl -u SERVICE (-u ist besser als -t, da es auch die Meldungen von systemd enthält)
• Logmeldungen in umgekehrter Reihenfolge: journalctl -r
• Rechnernamen in Logmeldungen unterdrücken: journalctl --no-hostname
• Boot-Zeitpunkte auflisten: journalctl --list-boots
• Sollte journald mal aussteigen, gibt es auch noch Meldungen im Kernel-Log mit dmesg.

Dauerhaft Logs aktivieren

Die Logs von journald werden in der Grundeinstellung (Storage=auto in /etc/systemd/journald.conf) nur dann dauerhaft gespeichert, wenn das Verzeichnis /var/log/journal existiert. Anderenfalls beginnt das Journal nach jedem Neustart von vor. Nach dem Erstellen des Verzeichnisses muss jounald nicht neu gestartet werden. Das aktuelle Protokoll wird am Ende in das Verzeichnis übertragen.

Cron-Jobs von Hand starten

Wenn es bei der Ausführung eines Cron-Jobs Probleme gab, kann man diesen mit systemctl start cron-daily.target noch einmal ausführen.

Speicherbegrenzung von Diensten

Damit ein Dienst nicht den kompletten RAM des Systems nutzen kann und dadurch andere Prozesse behindert, kann man unter Linux mit cgroups die Ressourcen beschränken. Systemd bietet hierfür auch praktische Einstellungen in den Konfig-Dateien, so dass diese mit systemctl edit gut zu einem Dienst hinzufügen kann. Beschrieben sind all diese Parameter in systemd.resource-control(5)

[Service]
# Ab dieser Grenze wird der Dienst ausgebremst
MemoryHigh=80%
# Hier ist dann Schluss und der OOM-Killer schlägt zu
MemoryMax=85%

Journal-Namen für Dienste festlegen

Systemd verwendet für die Protokolle bei Journald den Namen des Prozesses, was bei Programmen mit Interpretern wie python oder perl nicht passt. Daher kann man selbst den Namen setzen:

[Service]
SyslogIdentifier=my-srv

Damit funktioniert dann auch die Suche mit journalctl -t my-srv.

Bootprozess analysieren

Systemd bringt gleich Werkzeuge zur Analyse des Bootprozess' mit, um zum Beispiel zu erkennen, welche Dienste beim Start lange brauchen. Mit systemd-analyze blame bekommt man die Units mit ihrer Ausführungszeit aufgelistet und mit systemd-analyze plot > /tmp/boot.svg kann man eine Grafik erstellen, in der der Bootablauf genau zu erkennen ist.

Mit systemd-analyze time bekommt man eine Gesamtauswertung des Bootvorgangs und sieht die benötigte Zeit in den Etappen firmware, loader, kernel und userspace, bis das System gestartet war:

# systemd-analyze time
Startup finished in 8.067s (firmware) + 8.250s (loader) + 5.515s (kernel) + 9.423s (userspace) = 31.257s
graphical.target reached after 9.416s in userspace

Um konkret für eine bestimmte Unit zu ermitteln, wann sie bereit war und warum es so lange gedauert hat, kann man mit systemd-analyze critical-chain

% systemd-analyze critical-chain systemd-networkd.socket
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

systemd-networkd.socket @493ms
└─system.slice @361ms
  └─-.slice @361ms

% systemd-analyze --user critical-chain syncthing.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

syncthing.service @68ms
└─basic.target @66ms
  └─sockets.target @66ms
    └─dbus.socket @62ms +3ms
      └─-.slice @57ms

D-Bus mit systemd verwalten

Unter Debian sollte man das Paket dbus-x11 gegen dbus-user-session ersetzen, wenn man systemd installiert hat.