Version vom 11. September 2015, 19:34 Uhr

Dieser Artikel oder Teile davon wurden mit 'Review' markiert. Das bedeutet, dass größere Arbeiten am Inhalt des Artikels abgeschlossen sind und der Autor eine Korrekturlesung durch andere User zur Qualitätssicherung für angebracht hält.

Zu sichtende Teile: Kompletter Artikel

Bitte hilf LinuxClubWiki, indem du den zu sichtenden Teil überprüfst und den Artikel gegebenenfalls überarbeitest!

Aus technischen Gründen ist es leider nicht Möglich der korrekten Schreibweise von "systemd" in der Überschrift dieses Artikels gerecht zu werden.

Was ist systemd?

Systemd ist ein Dienst oder Daemon und bietet einige grundlegende Werkzeuge für Linux Systeme. Er wird zur System- und Diensteverwaltung eingesetzt. Er läuft mit PID1 und startet dann alle weiteren Prozesse des Betriebssystems.

http://www.freedesktop.org/wiki/Software/systemd/

Er startet also als erstes (PID1), regelt und steuert dabei alle weiteren Dienste. Er beendet sich beim Herunterfahren als letztes. Der daemon systemd ist damit also tief im Ablauf eines Systemstarts verwurzelt. Siehe Bootvorgang.

SUSE wechsel zu systemd

Mit unter libervoll vollzieht sich der Wechsel zu systemd als Init-System in SUSE mit Sätzen, zitert aus den Releasenotes und dem Adminguide zu SUSE Linux Enterprise Server 12, wie:

New core technologies like systemd (replacing the time honored System V based init process)

Versuchsweise frei übersetzt: Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).

Starting with SUSE Linux Enterprise Server 12 systemd is a replacement for the popular System V init daemon. systemd is fully compatible with System V init (by supporting init scripts).

Versuchsweise frei übersetzt: Beginnend mit SUSE Linux Enterprise Server 12 ist systemd ein Ersatz für den populären System V init daemon. Er ist voll kompatibel mit dem System V Init-Vorgang, indem er Init Skripte unterstützt.

Abwärts Kompatibilität

Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:

kompatibel mit LSB init Skripten
kompatibel mit SysV

Fähigkeiten

Als Verwaltungsinstrument bringt systemd einige Neuerungen und Verbesserungen, setzt dabei allerdings auch stark auf alt bewährtes. Um nur einiges an Neuerungen und Fähigen zu nennen:

Fähigkeit zur aggressiven Parallelisierung
Nutzt Socket und D-Bus Aktivierung um Prozesse zu starten
Bietet ein "auf Bedarf"-basiertes starten von Diensten
Überwacht Prozesse die cgroups verwenden
unterstützt Schnappschüsse und deren Wiederherstellung
Verwaltet mount und automount Einhängepunkte
Implementiert abhängigkeitsbasierte Logik für Dienste
Kann SysV-Init als drop-in ersetzen.
uvm.

systemd Steuern

Es gibt verschiedene Wege, wie systemd gesteuert werden kann. Einmal gibt es grafische Tools, wie die Dienste-Verwaltung in YaST. Das ehemals benannte Menü: "Runlevel-Editor" nennt sich heute bei Migration zu systemd "Dienste-Verwaltung". Dann gibt es noch die Möglichkeit mit der Shell. Eine vollständige auflistung der Steuerungsmöglichkeiten, würde den Rahmen dieser Doku total sprengen. Ich nenne hier einige aus Nutzersicht durchaus wichtige Möglichkeiten:

Mitgelieferte Tools:
systemctl	(Den System- und Dienstmanager steuern.)
journalctl	(Das systemd journal abfragen. Also logs.)
systemd-tmpfiles	(Erstellt und löscht temporäre Strukturen.)
systemd-analyze	(Analysiert die boot Geschwindigkeit.)
.. uvm.	(Alle die ich nicht nennen konnte)

Umgang mit systemctl

Bitte zum detaillierten Umgang mit systemctl die Manpage lesen. Oder beispielsweise im (Achtung externer Link): Adminguide nachschlagen.

man systemctl

Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.

Dienste starten und beenden

Starten

systemctl start mein_dienst

Beenden

systemctl stop mein_dienst

Automatischen Start De-/Aktivieren

Automatischen Start aktivieren:

systemctl enable mein_dienst

Automatischen Start deaktivieren:

systemctl disable mein_dienst

Status eines Dienstes abfragen

systemctl status mein_dienst

In der Ausgabe würde das bei einem erfolgreich gestarteten und für den automatischen Start konfigurierten Dienst in etwa so aussehen:

mein_dienst.service - mein_dienst Daemon
   Loaded: loaded (/usr/lib/systemd/system/mein_dienst.service; enabled)
   Active: active (running) since Sa 2015-08-22 02:17:01 CEST; 1s ago
  Process: 6717 ExecStartPre=/usr/sbin/mein_dienst (code=exited, status=0/SUCCESS)
 Main PID: 6721 (mein_dienst)

systemd neu laden

Angenommen, man hätte beispielsweise Änderungen an mein_dienst.service Dateien vorgenommen, muss systemd neu geladen werden, damit sie sofort wirksam werden.

systemctl daemon-reload

Wo sind meine Logs hin?

Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:

less /var/log/README

Darin steht in etwa (versuchsweise frei übersetzt):

Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?

Hier eine erklärung, was vor sich geht:

Sie betreiben ein systemd basiertes BS in dem syslog durch das Journal ersetzt wurde. Das Journal speichert die selben (und mehr) Informationen wie das klassische syslog. Um das Journal zu nutzen und auf die Logdaten zuzugreifen, führen Sie einfach "journalctl" aus, welches die Logdaten in dem identischen textbasierten Format ausgeben wird, wie es auch mit syslog der Fall war. Für weitere Details, sehen Sie bitte journalctl(1) ein.
...
Thank you!

Das heisst, man hat hier Gelegenheit sich mit dem neuen Journal vertraut zu machen. In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.

Umgang mit journalctl

Der Dienst systemd beinhaltet seinen eigenen Dienst zur Systemprotokollierung. Die Sammlung all dieser Informationen wird als journal bezeichnet. Diese Instanz sammelt wichtige Informationen und stellt diese wiederum zur Abfrage bereit. Das ist insbesondere zur Systemüberwachung von Nutzen. Es kann beispielsweise mit Hilfe von journalctl ein fehlerhafter Systemstart diagnostiziert werden. Angenommen dies wäre der Fall, so wird spätestens an dieser Stelle ein gewisses Grundwissen zum Umgang mit journalctl erforderlich, wenn es darum geht konkrete Fehlermeldungen bereitzustellen.

Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.

Das komplette journal betrachten:

journalctl

Wenn man einfach nur 'journalctl' aufruft, wird das gesamte journal angezeigt. Beginnend mit dem ältesten Eintrag.

Nützliche Filter

Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:

Schalter
"-b"	Bootvorgänge
"-k"	dmesg betrachten
"-u"	Nach Unit bzw. Dienst

Für mehr details bitte die manpage lesen.

Das Startprotokoll

journalctl -b

Der Schalter '-b' sagt journalctl, man möchte das Startprotokoll betrachten.

Ein Protokoll filtern

Angenommen, man möchte nur ein bestimmtes Startprotokoll sehen. Etwa vom vorhergehenden systemstart:

journalctl --list-boots

(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann man als Indikator heranziehen. Beispielausgabe:

 ..
 ...
 -2 9daa81e2ec374cb1b6adba8d96896605 Sa 2015-08-29 23:26:53 CEST—Sa 2015-08-29 23:49:17 CEST
 -1 c430ed034607494ba2a3bc1ded4e4972 Sa 2015-08-29 23:49:35 CEST—Sa 2015-08-29 23:54:27 CEST
  0 1f3a7894d0f34f4392c5517b83279c4d Sa 2015-08-29 23:54:53 CEST—So 2015-08-30 16:22:40 CEST

Das Startprotokoll des vorangegangenen Systemstarts kann man sich dann einblenden, indem dieser Indikator angegeben wird:

journalctl -b -1

Filtern nach Unit

Angenommen man möchte, dass nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.

journalctl -u sshd

journalctl -xn

Angenommen man landet beim Systemstart von Linux aufgrund eines Fehlers in der Shell statt dem grafischen Modus, so schlägt systemd oft vor, es solle die Ausgabe von 'journalctl -xn' zu Rate gezogen werden.

journalctl -xn

Schalter
"-n"	Ausgabe auf die letzten 10 Zeilen beschränken.
"-x"	Blendet nützliche Hilfetexte in der Ausgabe ein.

Eigener Filter

Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll nach vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager umgeleitet:

journalctl | egrep "Error|Failed" | less

Umgang mit systemd-analyze

Der Befehl systemd-analyze kann dazu genutzt werden, die Leistung eines Systemstarts zu messen. Beispielsweise wie lange es dauert, bis ein bestimmtes festgelegtes Ziel beim Boot erreicht wurde. Ich möchte hier nur Kleinigkeiten zeigen, damit Verständnis erlangt werden kann, was denn bei einem Systemstart von gerade mal 20 Sekunden so alles abgeht. Auch hier bitte ich darum, zu Details wieder die manpage heranzuziehen.

Wie lange hat der letzte Systemstart gedauert?

Einfach ohne Zusätzliche Schalter:
systemd-analyze
Beispielausgabe:
Startup finished in 1.433s (kernel) + 493ms (initrd) + 17.842s (userspace) = 19.769s
Die Ausgabe sollte weitestgehend selbsterklärend sein. Angegebene Messwerte sind an diesem Beispiel in Sekunden und Millisekunden.

Messung grafisch darstellen

Es kann eine SVG Grafik als sog. "plot" erstellt werden, der in Details aufzeigt welche Systemdienste zu welcher Zeit gestartet wurden. Dabei wird visuell hervorgehoben, wie viel Zeit alle Dienste zur Initialisierung benötigten.

Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":

Startzeiten aller Prozesse:
systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg
Die SVG ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein.
Hier kann man sehr schön sehen, was systemd beim Startvorgang so alles anstellen muss. Und was denn eigentlich so alles in diesen 20 Sekunden passiert bis am Beispielsystem ein vollständiger Systemstart abgeschlossen ist.

Abhängigkeit im Startvorgang darstellen:

Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.

Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":
systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg
Das ist ein Einzeiler!

Tipp: systemd-tmpfiles

Der Dienst systemd-tmpfiles ist im System für die Verwaltung temporärer Dateisystemstrukturen zuständig. Er erstellt und löscht diese kann sie aber auch bereinigen. ..usw. Einige dieser Strukturen bestehen bei einem Linux Betriebssystem als persistenter bzw. weniger persistenter Ablagebereich. Gedacht ist das für Dateien, die nur vorübergehend begrenzt längerfristig vorhanden sein müssen.

Der Tipp dazu:

Bei openSUSE 13.2 werden diese Verzeichnisse nicht mehr wie früher unter Sys-V Init automatisch bereinigt.

Wer also wieder, wie früher ein Automatisches Reinigen dieser Systembereiche wünscht, müsste hier händisch einige Einstellungen korrigieren. Im folgenden Beispiel werden benannte Einstellungen gemacht:

Automatische Bereinigung
"/tmp" sehr Kurzfristige Dateien 2 Tage

"/var/tmp" längerfristig erwünschte Dateien 7 Tage

Dazu folgende Datei editeren:
pico /etc/tmpfiles.d/tmp.conf
Weiter müssten dazu nachfolgende Zeilen bei diesem Absatz:
# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
d /tmp 1777 root root -
d /var/tmp 1777 root root -
So abgeändert werden: Also statt "-", die Zeit in Tagen "d":
d /tmp 1777 root root 2d
d /var/tmp 1777 root root 7d

Tipp: weekly trim durch systemd

systemd bringt ein unit mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem realisiert werden kann.

manuell: Durch ausführen des trim Kommando in der Shell.
batched trim (eigener Script): Man schreibt sich einen eigenen Script.
mitgelieferte Scripte:

- SuSE bringt beispielsweise für btrfs einen durch sysconfig steuerbaren trim Script mit. (btrfs-trim.sh); - systemd bringt diese Möglichkeit als dienst oder unit.

Wichtig ist zu beachten dass diese kommandos nicht unnötig mehrfach ausgeführt werden. Einmal die Woche sollte völlig ausreichend sein.

Wer also beispielsweise die in openSUSE integrierte Trimfunktion nicht nutzen möchte, kann beispielsweise auch die von systemd mitgelieferte verwenden.

Folgendes sollte genügen um dies zu aktivieren: systemctl enable fstrim.timer

Es wird ein File mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung abgehandelt wird.

Der Dienst führt zurzeit folgendes Kommando aus: fstrim -a Was schlicht automatisch alle eingehängten Dateisysteme mit trim behandelt.

Quellen / Links:

Systemd: Unterschied zwischen den Versionen