Systemd: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
K (Wo sind meine Logs hin?)
K (Fähigkeiten: externe Verlinkung korrigiert)
 
(182 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
  
 
= Was ist systemd? =
 
= 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.  
+
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 [[https://de.wikipedia.org/wiki/Process_identifier PID1]] und startet dann alle weiteren Prozesse des Betriebssystems. Des weiteren wird er als freie Software unter der [[LGPL |LGPL 2.1+]] veröffentlicht und wurde in [[Programmierung|C geschrieben]].
  
 
* http://www.freedesktop.org/wiki/Software/systemd/
 
* 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]]. ''
+
''Er startet also als erstes ([[https://de.wikipedia.org/wiki/Process_identifier 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.''
 +
 
 +
'''Wichtiges dazu:'''
 +
* [[Bootmanager]]
 +
* [[Bootvorgang]]
 +
* [[YaST2_Dienste-Verwaltung|YaST2 Dienste-Verwaltung]]
 +
<br>
  
 
= SUSE wechsel zu systemd =
 
= 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:
+
Mit unter liebevoll vollzieht sich der Wechsel zu systemd als Init-System in SUSE mit Sätzen, zitert aus den Releasenotes und dem Adminguide zu [[https://www.suse.com/ SUSE Linux Enterprise Server 12]], wie:
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">New core technologies like systemd (replacing the time honored System V based init process) </pre></blockquote>
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">New core technologies like systemd (replacing the time honored System V based init process) </pre></blockquote>
 
'''Versuchsweise frei übersetzt:''' ''Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).''
 
'''Versuchsweise frei übersetzt:''' ''Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).''
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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). </pre></blockquote>
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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). </pre></blockquote>
'''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.''
+
'''Versuchsweise frei übersetzt:'''  ''Beginnend mit [[https://www.suse.com/ 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.''
 +
 
 +
= Integration in [[YaST]] =
 +
{|
 +
|rowspan=2|[[Bild:Yast.png]]
 +
|colspan=3|Wie sich systemd im grafischen Konfigurationstool für [[openSUSE]] integriert, könnt ihr hier sehen:
 +
|-
 +
|style="text-align:center;"| ---------->
 +
|style="text-align:center;"|[[YaST2_Dienste-Verwaltung|YaST2: Diensteverwaltung]]
 +
|style="text-align:center;"| <----------
 +
|-
 +
|}
  
=Abwärts Kompatibilität=
+
=Kompatibilität=
 
Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:
 
Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:
* kompatibel mit LSB init Skripten
+
<br>
 +
* kompatibel mit [https://de.wikipedia.org/wiki/Linux_Standard_Base LSB] init Skripten
 
* kompatibel mit SysV
 
* kompatibel mit SysV
 +
Hier gibt es zu beachten, dass systemd nicht vollständig rückwärts kompatibel ist.
 +
Einige Einschränkungen können hier nachgelesen werden: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
 +
 +
=Kritik=
 +
Da ich nicht unnötig falsches sagen möchte, was Kritik gegenüber systemd angeht. Und da ich nur einige Grundlagen objektiv darstellen will, kann ich dazu nicht viel sagen. Allerdings kann ich folgendes berichten:
 +
* Bei Linux Entwicklern als auch Benutzern steht systemd im Mittelpunkt der Kritik, da es im Ansatz sehr wichtige Kernfunktionen steuert und auch das alt eingefahrene SysV-Init ersetzen kann, bzw. kompatibel ist.
 +
* Zu diesem Thema gibt es massenweise Informationen im Internet.
 +
'''Ein besonders wichtiger Punkt:'''
 +
* Es gibt viele Gegner als auch Befürworter.
 +
<br>
 +
{{Hinweis|'''Wer möchte informiert sich darüber bitte detaillierter mithilfe einer Suchmaschine eigener Wahl.'''}}
 +
{{Hinweis|'''Das Forum würde sich hierfür als Diskussionsplatform anbieten, wer möchte. Es gibt sicher einige die an dieser Thematik interesse haben. http://forum.linux-club.de/'''}}<br>
 +
---------
 +
'''Meine Meinung zur Kritik:'''<br>
 +
(Wer mir diesen Raum nicht lassen möchte: Bitte "skipping").
 +
<br><br>
 +
''Ich finde es wichtig, dass derart grundlegende Kernstrukturen im Betriebssystem kritisiert werden, solange es zielführend und im Sinne eines sicheren und korrekten Funktionierens und damit im Sinne des Endverbrauchers als auch der Entwickler ist. Was ich nicht verstehen kann, wenn Leute nur sagen "systemd ist mist ich will wieder das alte SysV-Init, weil ich mit systemd nicht umgehen kann." Deswegen möchte ich hier sagen:''
 +
<br><br>
 +
"''Bitte ich gebe euch Gelegenheit, euch zu informieren. Und ich hoffe dies halbwegs richtig zu machen.''"
 +
---------
  
 
=Fähigkeiten=
 
=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:
+
Als Verwaltungsinstrument bringt systemd einige Neuerungen und Verbesserungen, setzt dabei allerdings auch stark auf alt bewährtes. Um nur einiges an Neuerungen und Fähigkeiten zu nennen:
  
 
* Fähigkeit zur aggressiven Parallelisierung
 
* Fähigkeit zur aggressiven Parallelisierung
* Nutzt Socket und D-Bus Aktivierung um Prozesse zu starten
+
* Nutzt Socket und [[https://en.wikipedia.org/wiki/D-Bus D-Bus]] Aktivierung um Prozesse zu starten
 
* Bietet ein "auf Bedarf"-basiertes starten von Diensten
 
* Bietet ein "auf Bedarf"-basiertes starten von Diensten
* Überwacht Prozesse die cgroups verwenden
+
* Überwacht Prozesse die [[https://en.wikipedia.org/wiki/Cgroups cgroups]] verwenden
* unterstützt Schnappschüsse und deren Wiederherstellung
+
* unterstützt [[https://de.opensuse.org/SDB:Snapper Schnappschüsse]] und deren Wiederherstellung
* Verwaltet mount und automount Einhängepunkte
+
* Verwaltet [[Zugriffsrechte#mount|mount und automount]] Einhängepunkte
 
* Implementiert abhängigkeitsbasierte Logik für Dienste
 
* Implementiert abhängigkeitsbasierte Logik für Dienste
 
* Kann SysV-Init als drop-in ersetzen.
 
* Kann SysV-Init als drop-in ersetzen.
 
* uvm.
 
* uvm.
 +
{{Hinweis|Mit Parallelisierung ist das Resultat dieser Prinzipien: [https://de.wikipedia.org/wiki/Nebenläufigkeit Nebenläufigkeit] bzw. [https://de.wikipedia.org/wiki/Parallele_Programmierung Parallele Programmierung] gemeint. <br>Die wörter [https://de.wikipedia.org/wiki/Bedarf Bedarf] und [[Systemd#Abhängigkeit_darstellen:|Abhängigkeit]] müssen in der Auflistung differenziert werden.}}
 +
<br>
  
 
=systemd Steuern=
 
=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:
+
Es gibt verschiedene Wege, wie systemd gesteuert werden kann. Einmal gibt es grafische Tools, wie die [[YaST2_Dienste-Verwaltung|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:
  
 
{| class="wikitable"
 
{| class="wikitable"
Zeile 46: Zeile 86:
 
|''(Das systemd journal abfragen. Also logs.)''
 
|''(Das systemd journal abfragen. Also logs.)''
 
|-
 
|-
|'''[[#Umgang_mit_systemd-tmpfiles|systemd-tmpfiles]]'''
+
|'''[[#Tipp: systemd-tmpfiles|systemd-tmpfiles]]'''
 
|''(Erstellt und löscht temporäre Strukturen.)''
 
|''(Erstellt und löscht temporäre Strukturen.)''
 
|-
 
|-
 
|'''[[#Umgang_mit_systemd-analyze|systemd-analyze]]'''
 
|'''[[#Umgang_mit_systemd-analyze|systemd-analyze]]'''
 
|''(Analysiert die boot Geschwindigkeit.)''
 
|''(Analysiert die boot Geschwindigkeit.)''
 +
|-
 +
|'''[[#Umgang_mit_loginctl|loginctl]]'''
 +
|''(Anbindung an die Sitzungsverwaltung)''
 
|-
 
|-
 
|'''.. uvm.'''
 
|'''.. uvm.'''
Zeile 58: Zeile 101:
  
 
=Umgang mit systemctl=
 
=Umgang mit systemctl=
Bitte zum detaillierten Umgang mit systemctl die Manpage lesen. Oder beispielsweise im (Achtung externer Link): [https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_boot_systemd_basics.html Adminguide] nachschlagen.
+
Bitte zum detaillierten Umgang mit systemctl die [[Man_pages|manpage]] lesen. Oder beispielsweise im (Achtung externer Link): [https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_boot_systemd_basics.html Adminguide] nachschlagen.
 
<pre style="background-color: #FFFFC0">man systemctl</pre>
 
<pre style="background-color: #FFFFC0">man systemctl</pre>
 
Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.
 
Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.
  
==Dienste starten und beenden==
+
==Dienste Starten und Beenden==
 
'''Starten'''
 
'''Starten'''
 
<pre style="background-color: #FFFFC0">systemctl start mein_dienst</pre>
 
<pre style="background-color: #FFFFC0">systemctl start mein_dienst</pre>
Zeile 86: Zeile 129:
  
 
==systemd neu laden==
 
==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.
+
Angenommen, es wurden beispielsweise Änderungen an mein_dienst.service Dateien vorgenommen, muss systemd neu geladen werden, damit sie sofort wirksam werden.
 
<pre style="background-color: #FFFFC0">systemctl daemon-reload</pre>
 
<pre style="background-color: #FFFFC0">systemctl daemon-reload</pre>
  
Zeile 92: Zeile 135:
 
{{Hinweis|'''Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:'''}}
 
{{Hinweis|'''Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:'''}}
 
<pre style="background-color: #FFFFC0">less /var/log/README</pre>
 
<pre style="background-color: #FFFFC0">less /var/log/README</pre>
'''Darin steht in etwa:'''<br>
+
'''Darin steht in etwa (versuchsweise frei übersetzt):'''<br>
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
 
Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?
 
Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?
Zeile 98: Zeile 141:
 
Hier eine erklärung, was vor sich geht:
 
Hier eine erklärung, was vor sich geht:
  
Sie betreiben ein systemd-basiertes BS in dem syslog durch das Journal ersetzt wurde.
+
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.
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 einfahc "journalctl"  
+
Thank you!
aus, welches die Logs 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.
 
 
</pre></blockquote>
 
</pre></blockquote>
Das heisst, man hat hier Gelegenheit sich mit dem neuen Journal vertraut zu machen.  
+
Das heisst, es bietet sich hier die Gelegenheit mit dem neuen Journal vertraut zu werden.  
 
In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.
 
In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.
  
Zeile 110: Zeile 151:
 
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.
 
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.
 
{{Hinweis|'''Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.'''}}
 
{{Hinweis|'''Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.'''}}
==Das komplette journal betrachten:==
+
==Das journal betrachten:==
 
<pre style="background-color: #FFFFC0">journalctl</pre>
 
<pre style="background-color: #FFFFC0">journalctl</pre>
Wenn man einfach nur 'journalctl' aufruft, wird das gesamte journal angezeigt. Beginnend mit dem ältesten Eintrag.
+
Wenn einfach nur 'journalctl' ausgeführt wird, zeigt ein pager das komplette journal, beginnend mit dem ältesten Eintrag.
  
==Nützliche Filter==
+
==Nützliche Schalter==
 
Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:
 
Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:
 
{| class="wikitable"
 
{| class="wikitable"
 
|+Schalter
 
|+Schalter
 +
|-
 +
|"-k"
 +
|dmesg betrachten
 
|-
 
|-
 
|"-b"
 
|"-b"
 
|Bootvorgänge
 
|Bootvorgänge
|-
 
|"-k"
 
|dmesg betrachten
 
 
|-
 
|-
 
|"-u"
 
|"-u"
 
|Nach Unit bzw. Dienst
 
|Nach Unit bzw. Dienst
 +
|-
 +
|"-f"
 +
|aktualisiert den Pager mit neuen Einträgen
 
|}
 
|}
Für mehr details bitte die manpage lesen.
+
Für mehr Details bitte die [[Man_pages|manpage]] lesen.
  
 
==Das Startprotokoll==
 
==Das Startprotokoll==
 
<pre style="background-color: #FFFFC0">journalctl -b</pre>
 
<pre style="background-color: #FFFFC0">journalctl -b</pre>
Der Schalter '-b' sagt journalctl, man möchte das Startprotokoll betrachten.
+
Der Schalter '-b' sagt journalctl, dass das gesamte Startprotokoll gezeigt werden soll.
  
==Ein Protokoll filtern==
+
===Das Startprotokoll filtern===
Angenommen, man möchte nur ein bestimmtes Startprotokoll sehen. Etwa vom vorhergehenden systemstart:
+
Angenommen, es möchte nur ein bestimmtes Startprotokoll eingesehen werden. Etwa vom vorhergehenden Systemstart:
 
<pre style="background-color: #FFFFC0">journalctl --list-boots</pre>
 
<pre style="background-color: #FFFFC0">journalctl --list-boots</pre>
(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann man als Indikator heranziehen. Beispielausgabe:
+
(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann als Indikator herangezogen werden. Beispielausgabe:
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> ..
 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> ..
 
  ...
 
  ...
Zeile 143: Zeile 187:
 
  -1 c430ed034607494ba2a3bc1ded4e4972 Sa 2015-08-29 23:49:35 CEST—Sa 2015-08-29 23:54:27 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</pre></blockquote>
 
   0 1f3a7894d0f34f4392c5517b83279c4d Sa 2015-08-29 23:54:53 CEST—So 2015-08-30 16:22:40 CEST</pre></blockquote>
Das Startprotokoll des vorangegangenen Systemstarts kann man sich dann einblenden, indem dieser Indikator angegeben wird:
+
Das gewünschte Startprotokoll wird durch Übergabe des jeweiligen Indikator im Pager dargestellt:
 
<pre style="background-color: #FFFFC0">journalctl -b -1</pre>
 
<pre style="background-color: #FFFFC0">journalctl -b -1</pre>
  
==Filtern nach Unit==
+
===journalctl -xb===
Angenommen man möchte, dass nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.
+
Wenn der Computer beispielsweise aufgrund eines Stromausfall im Emergency Mode startet, wird in der Shell statt dem grafischen Modus ein Login angeboten. Hier schlägt der Rechner oft vor, es solle die Ausgabe von 'journalctl -xb' zu Rate gezogen werden. Also das Startprotokoll prüfen:
<pre style="background-color: #FFFFC0">journalctl -u sshd</pre>
+
<pre style="background-color: #FFFFC0">journalctl -xb</pre>
 +
{| class="wikitable"
 +
|+ Schalter
 +
|-
 +
|"-x"
 +
|Blendet nützliche Hilfetexte in der Ausgabe ein.
 +
|-
 +
|"-b"
 +
|Das Bootprotokoll anzeigen.
 +
|-
 +
|}
  
 
==journalctl -xn==
 
==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.
+
Duch den Schalter -n kann man die Ausgabe auf eine bestimmte Anzahl Zeilen beschränken. Wenn keine Zahl übergeben wird, werden die letzten 10 Zeilen ausgegeben. Beispielsweise die letzten 25 Zeilen ausgeben und Hilfstexte einblenden:
<pre style="background-color: #FFFFC0">journalctl -xn</pre>
+
<pre style="background-color: #FFFFC0">journalctl -xn 25</pre>
 
{| class="wikitable"
 
{| class="wikitable"
 
|+ Schalter
 
|+ Schalter
|-
 
|"-n"
 
|Ausgabe auf die letzten 10 Zeilen beschränken.
 
 
|-
 
|-
 
|"-x"
 
|"-x"
 
|Blendet nützliche Hilfetexte in der Ausgabe ein.
 
|Blendet nützliche Hilfetexte in der Ausgabe ein.
 +
|-
 +
|"-n"
 +
|Ausgabe auf bestimmte Zeilenanzahl beschränken.
 
|-
 
|-
 
|}
 
|}
 +
 +
==Filtern nach Unit==
 +
Angenommen es sollen nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.
 +
<pre style="background-color: #FFFFC0">journalctl -u sshd</pre>
  
 
==Eigener Filter==
 
==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:
+
Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll unter zuhilfenahme von 'egrep' nach Vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager (less) umgeleitet:
 
<pre style="background-color: #FFFFC0">journalctl | egrep "Error|Failed" | less</pre>
 
<pre style="background-color: #FFFFC0">journalctl | egrep "Error|Failed" | less</pre>
 +
 +
==Speicherplatzbelegung==
 +
Jedes Log wird für eine gewisse Dauer aufbewahrt. Das ist besonders für Systemadministratoren von besonderer Bedeutung, da Computer oft über einen längeren Zeitraum überwacht werden müssen. Einige Daten werden also permanent auf der Festplatte abgelegt. Von Haus aus sind seitens systemd für diese Informationen 10 Prozent des betroffenen Dateisystems vorgesehen. Bei einem Dateisystem mit 1 TiB Speicherplatz wären dies also 100 GiB logdaten, die von systemd angesammelt würden. Das Journal wird allerdings auch noch komprimiert.
 +
{| class="wikitable"
 +
|+Schalter für journalctl
 +
|-
 +
|"--disk-usage"
 +
|Speicherplatzbelegung des Journal auf dem Datenträger zeigen.
 +
|}
 +
Wer auf die voreingestellten Limits und den dafür vorgesehenen Speicherplatz Einfluss haben möchte, kann dies in der Konfigurationsdatei tun:
 +
<blockquote><pre style="background-color: #D4FFEF">/etc/systemd/journald.conf</pre></blockquote>
 +
So liesse sich beispielsweise mit diesem Schalter das Journal auf eine Größe von 100M beschränken. Ich fände auch einen Wert bis 300M noch sinnvoll wieviel hier eingestellt wird, liegt an der eigenen Nutzenvorstellung:
 +
<pre style="background-color: #FFFFC0">SystemMaxUse=100M</pre>
 +
Zum Verständnis der Grössenrelation: [[Megabyte |Megabyte/Mibibyte]]<br>
 +
Und Achtung externer Link: https://de.wikipedia.org/wiki/Datenmenge
 +
{{Hinweis|'''Die Daten werden im Journal in anderer Form und komprimiert abgelegt. Dennoch, um eine Vorstellung zu haben: <br><br>Eine Textdatei gefüllt mit Rautezeichen, die ein A4 Brief ausfüllen würden, hat ca. 4,1 KiB. Eine Ansammlung von 100 GiB mit solchen Dateien entspräche in etwa 261 888 249 Dokumente oder Seiten. Eine Packung Schreibmaschinenpapier hat ca 100 Blatt.'''}}
 +
<br>
  
 
=Umgang mit systemd-analyze=
 
=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.
 
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?==
+
==Startzeitanalyse==
 
<blockquote>'''Einfach ohne Zusätzliche Schalter:'''
 
<blockquote>'''Einfach ohne Zusätzliche Schalter:'''
 
<pre style="background-color: #FFFFC0">systemd-analyze</pre>
 
<pre style="background-color: #FFFFC0">systemd-analyze</pre>
Zeile 180: Zeile 255:
  
 
==Messung grafisch darstellen==
 
==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.
+
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.<br>
 +
-----
 +
==='''Startzeiten aller Prozesse:'''===
 
<blockquote>{{Hinweis|'''Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":'''}}
 
<blockquote>{{Hinweis|'''Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":'''}}
'''Startzeiten aller Prozesse:'''
 
 
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg</pre>
 
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg</pre>
{{Achtung|Die SVG ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein.}}  
+
{{Achtung|Die SVG Datei ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein. Nachfolgend nur ein kleiner Ausschnitt aus so einer Grafik als GIF.}}
 +
[[Bild:systemd-analyze_plot.gif|center|'''Plot als Grafik''']]
 
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.<br></blockquote>
 
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.<br></blockquote>
 
--------
 
--------
'''Abhängigkeit im Startvorgang darstellen:'''<br>
+
==='''Abhängigkeit darstellen:'''<br>===
 
<blockquote>Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.
 
<blockquote>Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.
 
{{Hinweis|'''Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":'''}}
 
{{Hinweis|'''Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":'''}}
  
 
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg</pre>{{Achtung|'''Das ist ein Einzeiler!'''}}
 
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg</pre>{{Achtung|'''Das ist ein Einzeiler!'''}}
 +
Das Ergebnis präsentiert sich dann so (zu .gif umgewandelt):
 +
[[Bild:Systemd-analyze_avahi.gif|center|'''Prozessabhängigkeit als Grafik''']]
 
</blockquote>
 
</blockquote>
 
<br>
 
<br>
  
=Tipp: systemd-tmpfiles=
+
=Umgang mit loginctl=
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.
+
Als wichtiger Systemdienst bindet sich systemd auch an den Anmeldevorgang im Betriebssystem. Dafür stellt er einen extra Dienst "systemd-login" zur Verfügung. Der Dienst bietet an dieser Stelle ein Anbindung an die D-Bus Schnittstelle. Wichtige Grundlagen betreffend Zugriffsberechtigungen: [[Zugriffsrechte]]
 +
 
 +
Das Tool loginctl kann dazu verwendet werden, Einblicke in den Status von Benutzeranmeldungen zu erlangen. Ausserdem kann es verwendet werden Veränderungen am Systemstatus vorzunehmen.
 +
 
 +
So können [[https://de.wikipedia.org/wiki/Portable_Operating_System_Interface POSIX]] kompatible Signale an Benutzersitzungen gesendet werden, wie beispielsweise [[https://de.wikipedia.org/wiki/SIGTERM SIGTERM]]. Das ist ein Signal zum Terminieren von Programmprozessen.
 +
{{Warnung|'''Dieses Werkzeug sollte nur von erfahrenen Benutzern verwendet werden.'''}}
 +
'''Hier nur ein ganz einfaches ungefährliches Anwendungsbeispiel:'''
 +
<pre style="background-color: #FFFFC0">loginctl</pre>
 +
'''Listet laufende Benutzersitzungen:'''
 +
<blockquote><pre style="background-color: #D4FFEF">  SESSION        UID USER            SEAT           
 +
        1      1000 user            seat0</pre></blockquote>
 +
<br>
 +
 
 +
=systemd-tmpfiles=
 +
'''Grundlegendes:'''<br>
 +
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 entweder vorübergehend bzw. begrenzt oder längerfristig vorhanden sein müssen.
 +
 
 +
'''Interessant und erwähnenswert an dieser Stelle:'''<br>
 +
Systemd hängt einige Dateisystemstrukturen automatisch als "tmpfs" ein. Dazu gehört beispielsweise auch der Pfad "/tmp". Wie dies geschieht, kann anhand des betreffenden tmp.mount units eingesehen werden. Aus dem Inhalt ergibt sich:
 +
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">[Mount]
 +
What=tmpfs
 +
Where=/tmp
 +
Type=tmpfs
 +
Options=mode=1777,strictatime</pre></blockquote>
 +
'''Ein zu SysV-Init zeiten nötiger [[fstab|fstab Eintrag]] hätte so ausgesehen:'''
 +
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">tmpfs                /tmp                tmpfs      defaults,strictatime,mode=1777 0 0</pre></blockquote>
 
<blockquote>
 
<blockquote>
'''Der Tipp dazu:'''
+
{{Hinweis|'''Der Pfad '/var/tmp/' wird hingegen beispielsweise nicht als tmpfs eingehängt. Ist dafür auch nicht bestimmt.'''}}
{{Hinweis|Bei '''openSUSE 13.2''' werden diese Verzeichnisse '''nicht mehr wie früher''' unter Sys-V Init automatisch bereinigt.}}
+
</blockquote>
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:
+
 
 +
{{Achtung|'''Der Tipp dazu: [[Tipp: systemd-tmpfiles]]'''}}
 +
<br>
 +
 
 +
=Tipp: weekly trim durch systemd=
 +
Das Paket 'util-linux-systemd' bringt einen Dienst mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem zur [[SSD_Optimierungen|Optimierung von SSD's]] realisiert werden kann:
 
{| class="wikitable"
 
{| class="wikitable"
|+Automatische Bereinigung
+
|+ Trim
 +
|-
 +
|Online discard (trim)
 +
|moutoption "discard"
 +
|Ersetzt batched trim und Skripte sowie manuelle Ausführung.
 +
|-
 +
|Manuell
 +
|Durch ausführen des 'fstrim' Kommando in der Shell.
 +
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
 +
|-
 +
|rowspan="3"|Batched trim bzw. Mitgelieferte Skripte
 +
|(eigener Skript) Bsp.: [[http://linux-club.de/wiki/opensuse/Batched-trim.sh ext4-trim.sh]]
 +
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
 +
|-
 +
|openSUSE bringt beispielsweise für [[https://de.wikipedia.org/wiki/Btrfs btrfs]] einen durch sysconfig steuerbaren trim Skript mit. ('btrfs-trim.sh');
 +
|Funktioniert zum Stand von openSUSE 13.2 nur beim Einsatz von [[https://de.wikipedia.org/wiki/Btrfs btrfs]].
 
|-
 
|-
|"/tmp"
+
|systemd bringt diese Möglichkeit als Dienst oder unit. ('fstrim.timer') - ('fstrim.service')
|sehr Kurzfristige Dateien
+
|Keine Einschränkung durch "automatik". "fstrim -a" beispielsweise bei ext4.
|2 Tage
 
 
|-
 
|-
|"/var/tmp"
 
|längerfristig erwünschte Dateien
 
|7 Tage
 
 
|}
 
|}
'''Dazu folgende Datei editeren:'''
+
Wichtig ist zu beachten dass diese Kommandos nicht unnötig mehrfach ausgeführt werden oder vermischt zum Einsatz kommen. Einmal die Woche sollte bei batched trim völlig ausreichend sein. Wenn also die in openSUSE integrierte Trimfunktion nicht genutzt werden möchte, kann diese durch die von systemd durchaus ersetzt werden. Wenn beispielsweise Online discard verwendet wird, werden andere Skripte obsolet.
<pre style="background-color: #FFFFC0">pico /etc/tmpfiles.d/tmp.conf</pre>
+
{{Achtung|'''Ich möchte hier nochmal darauf hinweisen, dass andere Skripte bei Nutzung von systemd zu diesem Zweck deaktiviert werden sollten! Und bei der mount option discard wird batched trim obsolet.'''}}
'''Weiter müssten dazu nachfolgende Zeilen bei diesem Absatz:'''
+
'''Folgendes genügt zum aktivieren der systemd variante:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
+
<pre style="background-color: #FFFFC0">systemctl enable fstrim.timer</pre>
# Clear tmp directories separately, to make them easier to override
+
(''Der zugehörige fstrim.service wird vom Timer automatisch zur Ausführung aktiviert.'')
# SUSE policy: we don't clean those directories
+
{{Hinweis|'''Es wird eine Datei mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung nach dem ersten Aufruf abgehandelt wird.'''}}
d /tmp 1777 root root -
+
'''Der eigentliche Dienst heisst:'''
d /var/tmp 1777 root root -</pre></blockquote>
+
<blockquote><pre style="background-color: #D4FFEF">fstrim.service</pre></blockquote>
'''So abgeändert werden:'''
+
'''Eine Steuerungsmöglichkeit hierfür ist auch:'''
''Also statt "-", die Zeit in Tagen "d":
+
<pre style="background-color: #FFFFC0">rcfstrim</pre>
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">d /tmp 1777 root root 2d
+
'''Der Stempel befindet sich dann hier:'''
d /var/tmp 1777 root root 7d</pre></blockquote>
+
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/fstrim.timer</pre></blockquote>
</blockquote>
+
'''Der Dienst führt zurzeit wöchentlich folgendes Kommando aus:'''<br>
 +
''Dies behandelt schlicht und automatisch alle eingehängten Dateisysteme mit trim.''
 +
<pre style="background-color: #FFFFC0">fstrim -a</pre>
 +
{{Warnung|'''Nicht jede SSD und SATA controller unterstützen jede TRIM Funktionalität. D.h. einige Geräte sind auf batched-discard angewiesen. Einige können mit Online-discard arbeiten, andere nicht. Einige haben wiederum Schwierigkeiten bei trim in Verbindung mit NCQ.'''}}
 +
{{Hinweis|'''Es bietet sich auch an, dieses unit manuell durch einen eigenen Skript aufzurüsten.'''}}
 +
 
 +
<br>
  
 
=Quellen / Links:=
 
=Quellen / Links:=
Zeile 230: Zeile 356:
 
* http://www.freedesktop.org/wiki/Software/systemd/
 
* http://www.freedesktop.org/wiki/Software/systemd/
 
* https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_systemd.html
 
* https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_systemd.html
 +
* https://de.wikipedia.org
 +
* http://man7.org/
 +
*[https://fedoraproject.org/wiki/Systemd fedoraproject.org wiki] {{englisch}}
 +
*[http://cre.fm/cre209-das-linux-system CRE209 Das Linux System - systemd leitet die neue Generation der Linux Systemarchitektur ein] Tim Pritlove im Gespräch mit Lennart Poetering (Veröffentlicht am 10. November 2015)
  
[[Kategorie:Bootmanager‏‎]]
+
[[Kategorie:Bootmanager‏‎]] [[Kategorie:systemd]]

Aktuelle Version vom 20. November 2015, 19:22 Uhr

Höhe=24px 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. Des weiteren wird er als freie Software unter der LGPL 2.1+ veröffentlicht und wurde in C geschrieben.

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.

Wichtiges dazu:


SUSE wechsel zu systemd

Mit unter liebevoll 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.

Integration in YaST

Yast.png Wie sich systemd im grafischen Konfigurationstool für openSUSE integriert, könnt ihr hier sehen:
----------> YaST2: Diensteverwaltung <----------

Kompatibilität

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

  • kompatibel mit LSB init Skripten
  • kompatibel mit SysV

Hier gibt es zu beachten, dass systemd nicht vollständig rückwärts kompatibel ist. Einige Einschränkungen können hier nachgelesen werden: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

Kritik

Da ich nicht unnötig falsches sagen möchte, was Kritik gegenüber systemd angeht. Und da ich nur einige Grundlagen objektiv darstellen will, kann ich dazu nicht viel sagen. Allerdings kann ich folgendes berichten:

  • Bei Linux Entwicklern als auch Benutzern steht systemd im Mittelpunkt der Kritik, da es im Ansatz sehr wichtige Kernfunktionen steuert und auch das alt eingefahrene SysV-Init ersetzen kann, bzw. kompatibel ist.
  • Zu diesem Thema gibt es massenweise Informationen im Internet.

Ein besonders wichtiger Punkt:

  • Es gibt viele Gegner als auch Befürworter.


Wer möchte informiert sich darüber bitte detaillierter mithilfe einer Suchmaschine eigener Wahl.
Das Forum würde sich hierfür als Diskussionsplatform anbieten, wer möchte. Es gibt sicher einige die an dieser Thematik interesse haben. http://forum.linux-club.de/



Meine Meinung zur Kritik:
(Wer mir diesen Raum nicht lassen möchte: Bitte "skipping").

Ich finde es wichtig, dass derart grundlegende Kernstrukturen im Betriebssystem kritisiert werden, solange es zielführend und im Sinne eines sicheren und korrekten Funktionierens und damit im Sinne des Endverbrauchers als auch der Entwickler ist. Was ich nicht verstehen kann, wenn Leute nur sagen "systemd ist mist ich will wieder das alte SysV-Init, weil ich mit systemd nicht umgehen kann." Deswegen möchte ich hier sagen:

"Bitte ich gebe euch Gelegenheit, euch zu informieren. Und ich hoffe dies halbwegs richtig zu machen."


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ähigkeiten 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.
Mit Parallelisierung ist das Resultat dieser Prinzipien: Nebenläufigkeit bzw. Parallele Programmierung gemeint.
Die wörter Bedarf und Abhängigkeit müssen in der Auflistung differenziert werden.


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.)
loginctl (Anbindung an die Sitzungsverwaltung)
.. 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, es wurden 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, es bietet sich hier die Gelegenheit mit dem neuen Journal vertraut zu werden. 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 journal betrachten:

journalctl

Wenn einfach nur 'journalctl' ausgeführt wird, zeigt ein pager das komplette journal, beginnend mit dem ältesten Eintrag.

Nützliche Schalter

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

Schalter
"-k" dmesg betrachten
"-b" Bootvorgänge
"-u" Nach Unit bzw. Dienst
"-f" aktualisiert den Pager mit neuen Einträgen

Für mehr Details bitte die manpage lesen.

Das Startprotokoll

journalctl -b

Der Schalter '-b' sagt journalctl, dass das gesamte Startprotokoll gezeigt werden soll.

Das Startprotokoll filtern

Angenommen, es möchte nur ein bestimmtes Startprotokoll eingesehen werden. Etwa vom vorhergehenden Systemstart:

journalctl --list-boots

(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann als Indikator herangezogen werden. 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 gewünschte Startprotokoll wird durch Übergabe des jeweiligen Indikator im Pager dargestellt:

journalctl -b -1

journalctl -xb

Wenn der Computer beispielsweise aufgrund eines Stromausfall im Emergency Mode startet, wird in der Shell statt dem grafischen Modus ein Login angeboten. Hier schlägt der Rechner oft vor, es solle die Ausgabe von 'journalctl -xb' zu Rate gezogen werden. Also das Startprotokoll prüfen:

journalctl -xb
Schalter
"-x" Blendet nützliche Hilfetexte in der Ausgabe ein.
"-b" Das Bootprotokoll anzeigen.

journalctl -xn

Duch den Schalter -n kann man die Ausgabe auf eine bestimmte Anzahl Zeilen beschränken. Wenn keine Zahl übergeben wird, werden die letzten 10 Zeilen ausgegeben. Beispielsweise die letzten 25 Zeilen ausgeben und Hilfstexte einblenden:

journalctl -xn 25
Schalter
"-x" Blendet nützliche Hilfetexte in der Ausgabe ein.
"-n" Ausgabe auf bestimmte Zeilenanzahl beschränken.

Filtern nach Unit

Angenommen es sollen nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.

journalctl -u sshd

Eigener Filter

Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll unter zuhilfenahme von 'egrep' nach Vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager (less) umgeleitet:

journalctl | egrep "Error|Failed" | less

Speicherplatzbelegung

Jedes Log wird für eine gewisse Dauer aufbewahrt. Das ist besonders für Systemadministratoren von besonderer Bedeutung, da Computer oft über einen längeren Zeitraum überwacht werden müssen. Einige Daten werden also permanent auf der Festplatte abgelegt. Von Haus aus sind seitens systemd für diese Informationen 10 Prozent des betroffenen Dateisystems vorgesehen. Bei einem Dateisystem mit 1 TiB Speicherplatz wären dies also 100 GiB logdaten, die von systemd angesammelt würden. Das Journal wird allerdings auch noch komprimiert.

Schalter für journalctl
"--disk-usage" Speicherplatzbelegung des Journal auf dem Datenträger zeigen.

Wer auf die voreingestellten Limits und den dafür vorgesehenen Speicherplatz Einfluss haben möchte, kann dies in der Konfigurationsdatei tun:

/etc/systemd/journald.conf

So liesse sich beispielsweise mit diesem Schalter das Journal auf eine Größe von 100M beschränken. Ich fände auch einen Wert bis 300M noch sinnvoll wieviel hier eingestellt wird, liegt an der eigenen Nutzenvorstellung:

SystemMaxUse=100M

Zum Verständnis der Grössenrelation: Megabyte/Mibibyte
Und Achtung externer Link: https://de.wikipedia.org/wiki/Datenmenge

Die Daten werden im Journal in anderer Form und komprimiert abgelegt. Dennoch, um eine Vorstellung zu haben:

Eine Textdatei gefüllt mit Rautezeichen, die ein A4 Brief ausfüllen würden, hat ca. 4,1 KiB. Eine Ansammlung von 100 GiB mit solchen Dateien entspräche in etwa 261 888 249 Dokumente oder Seiten. Eine Packung Schreibmaschinenpapier hat ca 100 Blatt.


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.

Startzeitanalyse

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.


Startzeiten aller Prozesse:

Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":
systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg
Die SVG Datei ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein. Nachfolgend nur ein kleiner Ausschnitt aus so einer Grafik als GIF.
Plot als Grafik

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

Das Ergebnis präsentiert sich dann so (zu .gif umgewandelt):

Prozessabhängigkeit als Grafik


Umgang mit loginctl

Als wichtiger Systemdienst bindet sich systemd auch an den Anmeldevorgang im Betriebssystem. Dafür stellt er einen extra Dienst "systemd-login" zur Verfügung. Der Dienst bietet an dieser Stelle ein Anbindung an die D-Bus Schnittstelle. Wichtige Grundlagen betreffend Zugriffsberechtigungen: Zugriffsrechte

Das Tool loginctl kann dazu verwendet werden, Einblicke in den Status von Benutzeranmeldungen zu erlangen. Ausserdem kann es verwendet werden Veränderungen am Systemstatus vorzunehmen.

So können [POSIX] kompatible Signale an Benutzersitzungen gesendet werden, wie beispielsweise [SIGTERM]. Das ist ein Signal zum Terminieren von Programmprozessen.

Warnung
'Dieses Werkzeug sollte nur von erfahrenen Benutzern verwendet werden.'

Hier nur ein ganz einfaches ungefährliches Anwendungsbeispiel:

loginctl

Listet laufende Benutzersitzungen:

   SESSION        UID USER             SEAT            
         1       1000 user             seat0


systemd-tmpfiles

Grundlegendes:
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 entweder vorübergehend bzw. begrenzt oder längerfristig vorhanden sein müssen.

Interessant und erwähnenswert an dieser Stelle:
Systemd hängt einige Dateisystemstrukturen automatisch als "tmpfs" ein. Dazu gehört beispielsweise auch der Pfad "/tmp". Wie dies geschieht, kann anhand des betreffenden tmp.mount units eingesehen werden. Aus dem Inhalt ergibt sich:

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime

Ein zu SysV-Init zeiten nötiger fstab Eintrag hätte so ausgesehen:

tmpfs                /tmp                 tmpfs      defaults,strictatime,mode=1777 0 0
Der Pfad '/var/tmp/' wird hingegen beispielsweise nicht als tmpfs eingehängt. Ist dafür auch nicht bestimmt.
Der Tipp dazu: Tipp: systemd-tmpfiles


Tipp: weekly trim durch systemd

Das Paket 'util-linux-systemd' bringt einen Dienst mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem zur Optimierung von SSD's realisiert werden kann:

Trim
Online discard (trim) moutoption "discard" Ersetzt batched trim und Skripte sowie manuelle Ausführung.
Manuell Durch ausführen des 'fstrim' Kommando in der Shell. [man fstrim]
Batched trim bzw. Mitgelieferte Skripte (eigener Skript) Bsp.: [ext4-trim.sh] [man fstrim]
openSUSE bringt beispielsweise für [btrfs] einen durch sysconfig steuerbaren trim Skript mit. ('btrfs-trim.sh'); Funktioniert zum Stand von openSUSE 13.2 nur beim Einsatz von [btrfs].
systemd bringt diese Möglichkeit als Dienst oder unit. ('fstrim.timer') - ('fstrim.service') Keine Einschränkung durch "automatik". "fstrim -a" beispielsweise bei ext4.

Wichtig ist zu beachten dass diese Kommandos nicht unnötig mehrfach ausgeführt werden oder vermischt zum Einsatz kommen. Einmal die Woche sollte bei batched trim völlig ausreichend sein. Wenn also die in openSUSE integrierte Trimfunktion nicht genutzt werden möchte, kann diese durch die von systemd durchaus ersetzt werden. Wenn beispielsweise Online discard verwendet wird, werden andere Skripte obsolet.

Ich möchte hier nochmal darauf hinweisen, dass andere Skripte bei Nutzung von systemd zu diesem Zweck deaktiviert werden sollten! Und bei der mount option discard wird batched trim obsolet.

Folgendes genügt zum aktivieren der systemd variante:

systemctl enable fstrim.timer

(Der zugehörige fstrim.service wird vom Timer automatisch zur Ausführung aktiviert.)

Es wird eine Datei mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung nach dem ersten Aufruf abgehandelt wird.

Der eigentliche Dienst heisst:

fstrim.service

Eine Steuerungsmöglichkeit hierfür ist auch:

rcfstrim

Der Stempel befindet sich dann hier:

/usr/lib/systemd/system/fstrim.timer

Der Dienst führt zurzeit wöchentlich folgendes Kommando aus:
Dies behandelt schlicht und automatisch alle eingehängten Dateisysteme mit trim.

fstrim -a
Warnung
'Nicht jede SSD und SATA controller unterstützen jede TRIM Funktionalität. D.h. einige Geräte sind auf batched-discard angewiesen. Einige können mit Online-discard arbeiten, andere nicht. Einige haben wiederum Schwierigkeiten bei trim in Verbindung mit NCQ.'
Es bietet sich auch an, dieses unit manuell durch einen eigenen Skript aufzurüsten.


Quellen / Links: