Übersicht für systemctl

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

Übersicht für journalctl

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.