GNU/Linux >> LINUX-Kenntnisse >  >> Linux

5 Gründe, warum Systemadministratoren systemd lieben

Wie Systemadministratoren wissen, passiert auf modernen Computern viel. Anwendungen laufen im Hintergrund, automatisierte Events warten darauf, zu einem bestimmten Zeitpunkt ausgelöst zu werden, Logfiles werden geschrieben, Statusmeldungen werden zugestellt. Traditionell wurden diese unterschiedlichen Prozesse mit einer Sammlung von Unix-Tools mit großer Wirkung und großer Effizienz verwaltet und überwacht. Moderne Computer sind jedoch vielfältig, mit lokalen Diensten, die neben containerisierten Anwendungen ausgeführt werden, einfachem Zugriff auf Clouds und die Cluster, auf denen sie ausgeführt werden, Echtzeitprozessen und mehr zu verarbeitenden Daten als je zuvor.

Eine einheitliche Methode zu ihrer Verwaltung zu haben, ist eine Erwartung für Benutzer und ein nützlicher Luxus für vielbeschäftigte Systemadministratoren. Für diese nicht triviale Aufgabe wird der System-Daemon oder systemd verwendet , wurde entwickelt und schnell von allen wichtigen Linux-Distributionen übernommen.

Mehr über Systemadministratoren

  • Sysadmin-Blog aktivieren
  • Das automatisierte Unternehmen:ein Leitfaden zur IT-Verwaltung mit Automatisierung
  • eBook:Ansible-Automatisierung für SysAdmins
  • Geschichten aus der Praxis:Ein Leitfaden für Systemadministratoren zur IT-Automatisierung
  • eBook:Ein Leitfaden zu Kubernetes für SREs und Systemadministratoren
  • Neueste Sysadmin-Artikel

Natürlich ist systemd nicht die einzige Möglichkeit, ein Linux-System zu verwalten. Es gibt viele alternative Init-Systeme, darunter sysvinit, OpenRC, runit, s6 und sogar BusyBox, aber systemd behandelt Linux als einen einheitlichen Datensatz, der dazu bestimmt ist, konsistent mit robusten Tools bearbeitet und abgefragt zu werden. Für einen vielbeschäftigten Systemadministrator und viele Benutzer ist die Geschwindigkeit und Benutzerfreundlichkeit von systemd ein wichtiges Merkmal. Hier sind fünf Gründe dafür.

Startverwaltung

Das Booten eines Linux-Computers kann ein überraschend seltenes Ereignis sein, wenn Sie das möchten. Sicherlich werden in der Serverwelt Betriebszeiten oft in Jahren gezählt statt Monate oder Wochen. Laptops und Desktops werden in der Regel ziemlich häufig heruntergefahren und hochgefahren, obwohl selbst diese genauso wahrscheinlich angehalten oder in den Ruhezustand versetzt werden, wie sie heruntergefahren werden. In jedem Fall kann die Zeit seit dem letzten Boot-Ereignis als eine Art Sitzungsmanager für eine Computer-Gesundheitsprüfung dienen. Dies ist eine nützliche Methode, um einzuschränken, welche Daten Sie sich ansehen, wenn Sie Ihr System überwachen oder Probleme diagnostizieren.

Für den wahrscheinlichen Fall, dass Sie sich nicht erinnern können, wann Sie Ihren Computer das letzte Mal gebootet haben, können Sie Boot-Sessions mit dem Protokollierungstool von systemd, journalctl, auflisten :

$ journalctl --list-boots
-42 7fe7c3... Fri 2020-12-04 05:13:59 - Wed 2020-12-16 16:01:23
-41 332e99... Wed 2020-12-16 20:07:39 - Fri 2020-12-18 22:08:13
[...]
-1 e0fe5f... Mon 2021-03-29 20:47:46 - Mon 2021-03-29 21:59:29
 0 37fbe4... Tue 2021-03-30 04:46:13 - Tue 2021-03-30 10:42:08

Die letzten Startsitzungen erscheinen am Ende der Liste, sodass Sie die Ausgabe an tail weiterleiten können nur für die neuesten Stiefel.

Die Zahlen auf der linken Seite (42, 41, 1 und 0 in diesem Beispiel) sind Indexnummern für jede Startsitzung. Mit anderen Worten, um Protokolle nur für eine bestimmte Startsitzung anzuzeigen, können Sie deren Indexnummer als Referenz verwenden.

Überprüfungen protokollieren

Das Betrachten von Protokollen ist eine wichtige Methode zum Extrapolieren von Informationen über Ihr System. Protokolle bieten einen Verlauf vieler Aktivitäten, an denen Ihr Computer ohne Ihre direkte Überwachung beteiligt ist. Sie können sehen, wann Dienste gestartet wurden, wann zeitgesteuerte Jobs ausgeführt wurden, welche Dienste im Hintergrund ausgeführt werden, welche Aktivitäten fehlgeschlagen sind und vieles mehr. Einer der häufigsten anfänglichen Schritte zur Fehlerbehebung ist das Überprüfen von Protokollen, was mit journalctl einfach zu bewerkstelligen ist :

$ journalctl --pager-end

Der --pager-end (oder -e kurz) Option startet Ihre Ansicht der Protokolle am Ende des journalctl Ausgabe, also müssen Sie nach oben scrollen, um frühere Ereignisse zu sehen.

Systemd verwaltet einen "Katalog" von Fehlern und Meldungen, der mit Aufzeichnungen von Fehlern, möglichen Lösungen, Hinweisen auf Supportforen und Entwicklerdokumentation gefüllt ist. Dies kann einen wichtigen Kontext für ein Protokollereignis liefern, das ansonsten ein verwirrender Punkt in einem Meer von Nachrichten sein oder, schlimmer noch, völlig unbemerkt bleiben könnte. Um Fehlermeldungen mit erläuterndem Text einzubinden, können Sie den --catalog verwenden (oder -x kurz) Option:

$ journalctl --pager-end --catalog

Um die Protokollausgabe, die Sie durchlaufen müssen, weiter einzuschränken, können Sie angeben, für welche Startsitzung Sie Protokolle anzeigen möchten. Da jede Boot-Session indiziert ist, können Sie bestimmte Sessions mit --boot angeben Option und zeigen Sie nur die Protokolle an, die darauf zutreffen:

$ journalctl --pager-end --catalog --boot 42

Sie können auch Protokolle für eine bestimmte systemd-Einheit anzeigen. Um beispielsweise ein Problem mit Ihrem Secure Shell (SSH)-Dienst zu beheben, können Sie --unit sshd angeben um nur die Protokolle anzuzeigen, die für sshd gelten Dämon:

$ journalctl --pager-end \
--catalog --boot 42 \
--unit sshd

Dienstverwaltung

Die erste Aufgabe für systemd besteht darin, Ihren Computer zu booten, und dies geschieht im Allgemeinen schnell, effizient und effektiv. Aber die Aufgabe, die niemals abgeschlossen ist, ist das Servicemanagement. Systemd stellt standardmäßig sicher, dass die Dienste, die Sie ausführen möchten, tatsächlich starten und während Ihrer Sitzung weiter ausgeführt werden. Dies ist schön robust, da theoretisch sogar ein abgestürzter Dienst ohne Ihr Eingreifen neu gestartet werden kann.

Ihre Schnittstelle, um Systemd bei der Verwaltung von Diensten zu unterstützen, ist systemctl Befehl. Damit können Sie die Unit-Dateien anzeigen, die einen Dienst definieren:

$ systemctl cat sshd
# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Die meisten Unit-Dateien existieren in /usr/lib/systemd/system/ aber wie bei vielen wichtigen Konfigurationen werden Sie ermutigt, sie mit lokalen Änderungen zu modifizieren. Auch dafür gibt es eine Schnittstelle:

$ systemctl edit sshd

Sie können sehen, ob ein Dienst gerade aktiv ist:

$ systemctl is-active sshd
active
$ systemctl is-active foo
inactive

Ebenso können Sie mit is-failed sehen, ob ein Dienst fehlgeschlagen ist .

Das Starten und Stoppen von Diensten ist angenehm intuitiv:

$ systemctl stop sshd
$ systemctl start sshd

Und es ist ganz einfach, einen Dienst zum Starten beim Booten zu aktivieren:

$ systemctl enable sshd

Fügen Sie --now hinzu Option, um zu ermöglichen, dass ein Dienst beim Booten gestartet wird, oder um ihn für Ihre aktuelle Sitzung zu starten.

Timer

Als Sie vor langer Zeit eine Aufgabe unter Linux automatisieren wollten, war das kanonische Tool für diese Aufgabe cron . Es gibt immer noch einen Platz für den Cron-Befehl, aber es gibt auch einige überzeugende Alternativen. Zum Beispiel das anacron command ist ein vielseitiges, cron-ähnliches System, das Aufgaben ausführen kann, die andernfalls während der Ausfallzeit übersehen worden wären.

Geplante Ereignisse sind kaum mehr als Dienste, die zu einem bestimmten Zeitpunkt aktiviert werden, daher verwaltet systemd eine Cron-ähnliche Funktion namens Timers. Sie können aktive Timer auflisten:

$ systemctl list-timers
NEXT                          LEFT      
Tue 2021-03-30 12:37:54 NZDT  16min left [...]
Wed 2021-03-31 00:00:00 NZDT  11h left [...]
Wed 2021-03-31 06:42:02 NZDT  18h left [...]

3 timers listed.
Pass --all to see loaded but inactive timers, too.

Sie können einen Timer genauso aktivieren wie einen Dienst:

$ systemctl enable myMonitor.timer

Ziele

Ziele sind die letzte Hauptkomponente der systemd-Matrix. Ein Ziel wird durch eine Unit-Datei definiert, genauso wie Dienste und Timer. Targets können auch auf die gleiche Weise gestartet und aktiviert werden. Was Ziele einzigartig macht, ist, dass sie andere Unit-Dateien auf willkürlich signifikante Weise gruppieren. Beispielsweise möchten Sie möglicherweise eine Textkonsole anstelle eines grafischen Desktops starten, also den multi-user Ziel existiert. Allerdings ist die multi-user Ziel ist nur die graphical target ohne die Desktop-Unit-Dateien als Abhängigkeiten.

Kurz gesagt, Ziele sind eine einfache Möglichkeit für Sie, Dienste, Timer und sogar andere Ziele zu sammeln, um einen beabsichtigten Zustand für Ihren Computer darzustellen.

Tatsächlich ist innerhalb von systemd ein Neustart, ein Ausschalten oder eine Aktion zum Herunterfahren nur ein weiteres Ziel.

Sie können alle verfügbaren Ziele mit list-unit-files auflisten Option, indem Sie sie mit --type einschränken Option auf target gesetzt :

$ systemctl list-unit-files --type target

Kontrolle übernehmen mit systemd

Modernes Linux verwendet systemd für die Dienstverwaltung und die Protokoll-Introspektion. Es bietet alles von persönlichen Linux-Systemen bis hin zu Unternehmensservern mit einem modernen Mechanismus zur Überwachung und einfachen Wartung. Je öfter Sie es verwenden, desto besser wird systemd vorhersagbar und intuitiv und desto mehr entdecken Sie, wie unterschiedliche Teile Ihres Systems miteinander verbunden sind.

Um sich besser mit systemd vertraut zu machen, müssen Sie es verwenden. Und um sich mit der Verwendung vertraut zu machen, laden Sie unseren Spickzettel herunter und greifen Sie häufig darauf zurück.


Linux
  1. 10 Gründe, Linux im Jahr 2021 zu lieben

  2. 5 Gründe, warum ich es liebe, unter Linux zu programmieren

  3. Nicht-grafischer Boot mit Systemd?

  4. Gewusst wie:Verwalten von Systemprotokollen mit Journalctl

  5. So debuggen Sie den systemd-Startvorgang in CentOS/RHEL 7 und 8

systemd, um im Falle eines Boot-Fehlers einen automatischen Fallback auf einen älteren Kernel zu ermöglichen

So führen Sie ein Skript beim Booten in Debian 11 aus

Wie ich gelernt habe, mir keine Sorgen mehr zu machen und systemd zu lieben

So löschen Sie Systemd-Journalprotokolle

So verwenden Sie journalctl zum Anzeigen und Bearbeiten von Systemd-Protokollen

Journalctl:So lesen und bearbeiten Sie Systemd-Protokolle