Systemd lieben lernen

„Ich habe eigentlich keine besonders starke Meinung zu systemd selbst. Ich hatte Probleme mit einigen der Core-Entwickler, die meiner Meinung nach viel zu unbekümmert in Bezug auf Fehler und Kompatibilität sind, und ich denke, dass einige der Designdetails verrückt sind (I mag zum Beispiel die Binärlogs nicht), aber das sind Details, keine großen Probleme."

Für den Fall, dass Sie nicht viel über Linus wissen, kann ich Ihnen sagen, dass er, wenn er etwas nicht mag, seine Abneigung sehr offen und deutlich äußert. Er ist in seiner Art, seine Abneigung gegenüber Dingen anzusprechen, gesellschaftlich akzeptabler geworden.

Im Jahr 2013 schrieb Poettering einen langen Blogbeitrag, in dem er die Mythen über systemd entlarvt und gleichzeitig einen Einblick in einige der Gründe für seine Erstellung gibt. Dies ist eine sehr gute Lektüre und ich kann es nur wärmstens empfehlen.

systemd-Aufgaben

Abhängig von den während des Kompilierungsprozesses verwendeten Optionen (die in dieser Serie nicht berücksichtigt werden), kann systemd bis zu 69 ausführbare Binärdateien haben, die unter anderem die folgenden Aufgaben ausführen:

• Das systemd-Programm läuft als PID 1 und bietet einen Systemstart von so vielen Diensten wie möglich parallel, was als Nebeneffekt die Gesamtstartzeiten beschleunigt. Es verwaltet auch die Abschaltsequenz.
• Das Programm systemctl stellt eine Benutzerschnittstelle für die Dienstverwaltung bereit.
• Unterstützung für SystemV- und LSB-Startskripte wird aus Gründen der Abwärtskompatibilität angeboten.
• Dienstverwaltung und Berichterstellung bieten mehr Dienststatusdaten als SystemV.
• Es enthält Tools für die grundlegende Systemkonfiguration, wie Hostname, Datum, Gebietsschema, Listen angemeldeter Benutzer, laufende Container und virtuelle Maschinen, Systemkonten, Laufzeitverzeichnisse und -einstellungen, Daemons zur Verwaltung einfacher Netzwerkkonfiguration, Netzwerkzeitsynchronisierung , Protokollweiterleitung und Namensauflösung.
• Es bietet Socket-Management.
• Systemd-Timer bieten erweiterte Cron-ähnliche Fähigkeiten, um ein Skript zeitweise in Bezug auf den Systemstart, den Systemstart, den letzten Start des Timers und mehr auszuführen.
• Es bietet ein Tool zum Analysieren von Datums- und Zeitangaben, die in Timer-Spezifikationen verwendet werden.
• Das Mounten und Unmounten von Dateisystemen mit hierarchischem Bewusstsein ermöglicht eine sicherere Kaskadierung von gemounteten Dateisystemen.
• Es ermöglicht die positive Erstellung und Verwaltung von temporären Dateien, einschließlich des Löschens.
• Eine Schnittstelle zu D-Bus bietet die Möglichkeit, Skripte auszuführen, wenn Geräte angeschlossen oder entfernt werden. Dadurch können alle Geräte, ob steckbar oder nicht, als Plug-and-Play behandelt werden, was die Gerätehandhabung erheblich vereinfacht.
• Sein Tool zur Analyse der Startsequenz kann verwendet werden, um die Dienste zu finden, die die meiste Zeit in Anspruch nehmen.
• Es enthält Journale zum Speichern von Systemprotokollmeldungen und Tools zum Verwalten der Journale.

Architektur

Diese Aufgaben und mehr werden von einer Reihe von Daemons, Steuerprogrammen und Konfigurationsdateien unterstützt. Abbildung 1 zeigt viele der Komponenten, die zu systemd gehören. Dies ist ein vereinfachtes Diagramm, das einen allgemeinen Überblick bieten soll und daher nicht alle einzelnen Programme oder Dateien enthält. Es gibt auch keinen Einblick in den Datenfluss, der so komplex ist, dass er im Kontext dieser Artikelserie eine nutzlose Übung wäre.

Eine vollständige Darstellung von systemd würde ein eigenes Buch erfordern. Sie müssen nicht genau verstehen, wie die systemd-Komponenten in Abbildung 1 zusammenpassen; Es reicht aus, die Programme und Komponenten zu kennen, die es ermöglichen, verschiedene Linux-Dienste zu verwalten und mit Protokolldateien und Journalen umzugehen. Aber es ist klar, dass systemd nicht die monolithische Monstrosität ist, als die es von einigen seiner Kritiker behauptet wird.

systemd als PID 1

systemd ist PID 1. Einige seiner Funktionen, die weitaus umfangreicher sind als das alte SystemV3-Init-Programm, bestehen darin, viele Aspekte eines laufenden Linux-Hosts zu verwalten, einschließlich des Mountens von Dateisystemen und des Startens und Verwaltens von Systemdiensten, die für einen produktiven Linux-Host erforderlich sind. Alle Aufgaben von systemd, die sich nicht auf die Startsequenz beziehen, liegen außerhalb des Rahmens dieses Artikels (aber einige werden später in dieser Serie untersucht).

Zuerst mountet systemd die von /etc/fstab definierten Dateisysteme , einschließlich aller Auslagerungsdateien oder Partitionen. An diesem Punkt kann es auf die Konfigurationsdateien zugreifen, die sich in /etc befinden , einschließlich seiner eigenen. Es verwendet seinen Konfigurationslink /etc/systemd/system/default.target , um zu bestimmen, in welchen Zustand oder welches Ziel der Host gebootet werden soll. Das default.target file ist ein symbolischer Link auf die wahre Zieldatei. Bei einer Desktop-Workstation ist dies normalerweise graphical.target , was Runlevel 5 in SystemV entspricht. Für einen Server ist der Standardwert eher multi-user.target , was wie Runlevel 3 in SystemV ist. Das emergency.target ähnelt dem Einzelbenutzermodus. Ziele und Dienste sind systemd-Einheiten.

Die folgende Tabelle (Abbildung 2) vergleicht die systemd-Ziele mit den alten SystemV-Start-Runlevels. systemd stellt die Systemd-Zielaliase für die Abwärtskompatibilität bereit. Die Ziel-Aliase erlauben Skripten – und vielen Systemadministratoren – die Verwendung von SystemV-Befehlen wie init 3 Runlevel ändern. Natürlich werden die SystemV-Befehle zur Interpretation und Ausführung an systemd weitergeleitet.

Jedes Ziel hat eine Reihe von Abhängigkeiten, die in seiner Konfigurationsdatei beschrieben sind. systemd startet die erforderlichen Abhängigkeiten, bei denen es sich um die Dienste handelt, die erforderlich sind, um den Linux-Host auf einer bestimmten Funktionalitätsebene auszuführen. Wenn alle in den Zielkonfigurationsdateien aufgeführten Abhängigkeiten geladen sind und ausgeführt werden, wird das System auf dieser Zielebene ausgeführt. In Abbildung 2 befinden sich die Ziele mit den meisten Funktionen ganz oben in der Tabelle, wobei die Funktionalität zum Ende der Tabelle hin abnimmt.

systemd sieht auch in den alten SystemV-Init-Verzeichnissen nach, ob dort Startdateien vorhanden sind. Wenn dies der Fall ist, verwendet systemd sie als Konfigurationsdateien, um die von den Dateien beschriebenen Dienste zu starten. Der veraltete Netzwerkdienst ist ein gutes Beispiel für einen Dienst, der immer noch SystemV-Startdateien in Fedora verwendet.

Abbildung 3 (unten) wird direkt von der Bootup-Manpage kopiert. Es zeigt eine Karte der allgemeinen Abfolge von Ereignissen während des systemd-Starts und der grundlegenden Reihenfolgeanforderungen, um einen erfolgreichen Start sicherzustellen.

                                         cryptsetup-pre.target

                                                   |

 (various low-level                                v

     API VFS mounts:                 (various cryptsetup devices...)

  mqueue, configfs,                                |    |

  debugfs, ...)                                    v    |

  |                                  cryptsetup.target  |

  |  (various swap                                 |    |    remote-fs-pre.target

  |   devices...)                                  |    |     |        |

  |    |                                           |    |     |        v

  |    v                       local-fs-pre.target |    |     |  (network file systems)

  |  swap.target                       |           |    v     v                 |

  |    |                               v           |  remote-cryptsetup.target  |

  |    |  (various low-level  (various mounts and  |             |              |

  |    |   services: udevd,    fsck services...)   |             |    remote-fs.target

  |    |   tmpfiles, random            |           |             |             /

  |    |   seed, sysctl, ...)          v           |             |            /

  |    |      |                 local-fs.target    |             |           /

  |    |      |                        |           |             |          /

  \____|______|_______________   ______|___________/             |         /

                              \ /                                |        /

                               v                                 |       /

                        sysinit.target                           |      /

                               |                                 |     /

        ______________________/|\_____________________           |    /

       /              |        |      |               \          |   /

       |              |        |      |               |          |  /

       v              v        |      v               |          | /

  (various       (various      |  (various            |          |/

   timers...)      paths...)   |   sockets...)        |          |

       |              |        |      |               |          |

       v              v        |      v               |          |

 timers.target  paths.target   |  sockets.target      |          |

       |              |        |      |               v          |

       v              \_______ | _____/         rescue.service   |

                              \|/                     |          |

                               v                      v          |

                           basic.target         rescue.target    |

                               |                                 |

                       ________v____________________             |

                      /              |              \            |

                      |              |              |            |

                      v              v              v            |

                  display-    (various system   (various system  |

              manager.service     services        services)      |

                      |         required for        |            |

                      |        graphical UIs)       v            v

                      |              |            multi-user.target

 emergency.service    |              |              |

         |            \_____________ | _____________/

         v                          \|/

 emergency.target                    v

                              graphical.target

Das sysinit.target und basic.target Ziele können im Startprozess als Prüfpunkte betrachtet werden. Obwohl eines der Designziele von systemd darin besteht, Systemdienste parallel zu starten, müssen bestimmte Dienste und funktionale Ziele gestartet werden, bevor andere Dienste und Ziele gestartet werden können. Diese Kontrollpunkte können nicht passiert werden, bis alle von diesem Kontrollpunkt geforderten Dienste und Ziele erfüllt sind.

Das sysinit.target ist erreicht, wenn alle Einheiten, von denen es abhängt, abgeschlossen sind. Alle diese Einheiten, das Mounten von Dateisystemen, das Einrichten von Auslagerungsdateien, das Starten von udev, das Setzen des Zufallsgenerator-Seeds, das Initiieren von Low-Level-Diensten und das Einrichten von kryptografischen Diensten (wenn ein oder mehrere Dateisysteme verschlüsselt sind), müssen abgeschlossen werden, aber innerhalb der sysinit.target , können diese Aufgaben parallel ausgeführt werden.

Das sysinit.target startet alle Low-Level-Dienste und -Einheiten, die erforderlich sind, damit das System geringfügig funktionsfähig ist, und die erforderlich sind, um den Wechsel zum basic.target zu ermöglichen .

Nach sysinit.target erfüllt ist, startet systemd dann alle Einheiten, die zur Erfüllung des nächsten Ziels erforderlich sind. Das Basisziel bietet einige zusätzliche Funktionalität, indem Einheiten gestartet werden, die für alle nächsten Ziele erforderlich sind. Dazu gehört das Einrichten von Dingen wie Pfaden zu verschiedenen ausführbaren Verzeichnissen, Kommunikations-Sockets und Timern.

Schließlich die Ziele auf Benutzerebene, multi-user.target oder graphical.target , kann initialisiert werden. Das multi-user.target muss erreicht werden, bevor die grafischen Zielabhängigkeiten erfüllt werden können. Die unterstrichenen Ziele in Abbildung 3 sind die üblichen Startziele. Wenn eines dieser Ziele erreicht ist, ist der Startvorgang abgeschlossen. Wenn das multi-user.target die Standardeinstellung ist, dann sollten Sie eine Anmeldung im Textmodus auf der Konsole sehen. Wenn graphical.target die Standardeinstellung ist, dann sollten Sie eine grafische Anmeldung sehen; Der spezifische GUI-Anmeldebildschirm, den Sie sehen, hängt von Ihrem Standard-Display-Manager ab.

Die Bootup-Manpage beschreibt und stellt auch Abbildungen des Bootvorgangs in die anfängliche RAM-Disk und den systemd-Shutdown-Prozess bereit.

systemd bietet auch ein Tool, das Abhängigkeiten eines vollständigen Starts oder für eine bestimmte Einheit auflistet. Eine Unit ist eine steuerbare systemd-Ressourcenentität, die von einem bestimmten Dienst wie httpd oder sshd bis hin zu Timern, Mounts, Sockets und mehr reichen kann. Probieren Sie den folgenden Befehl aus und scrollen Sie durch die Ergebnisse.

systemctl list-dependencies graphical.target

Beachten Sie, dass dies die Zieleinheitenliste der obersten Ebene vollständig erweitert, die erforderlich ist, um das System in den grafischen Ziellaufmodus zu bringen. Verwenden Sie --all Möglichkeit, auch alle anderen Einheiten zu erweitern.

systemctl list-dependencies --all graphical.target

Sie können mit den Suchwerkzeugen von weniger nach Zeichenfolgen wie „Ziel“, „Slice“ und „Socket“ suchen Befehl.

Versuchen Sie jetzt Folgendes.

systemctl list-dependencies multi-user.target

und

systemctl list-dependencies rescue.target

und

systemctl list-dependencies local-fs.target

und

systemctl list-dependencies dbus.service

Dieses Tool hilft mir, die Besonderheiten der Startabhängigkeiten für den Host zu visualisieren, an dem ich arbeite. Machen Sie weiter und verbringen Sie einige Zeit damit, den Startbaum für einen oder mehrere Ihrer Linux-Hosts zu erkunden. Aber seien Sie vorsichtig, denn die Systemctl-Manpage enthält diesen Hinweis: