Analysieren Sie die Startleistung von Linux

Ein Teil der Aufgabe des Systemadministrators besteht darin, die Leistung von Systemen zu analysieren und Probleme zu finden und zu lösen, die zu schlechter Leistung und langen Startzeiten führen. Systemadministratoren müssen auch andere Aspekte der systemd-Konfiguration und -Nutzung prüfen.

Das Systemd-Init-System stellt die systemd-analyze bereit Tool, das dabei helfen kann, Leistungsprobleme und andere wichtige systemd-Informationen aufzudecken. In einem früheren Artikel Analysieren von systemd-Kalender und Zeitspannen , ich habe systemd-analyze verwendet um Zeitstempel und Zeitspannen in systemd-Timern zu analysieren, aber dieses Tool hat viele andere Verwendungsmöglichkeiten, von denen ich einige in diesem Artikel untersuchen werde.

Startup-Übersicht

Die Linux-Startsequenz ist ein guter Ausgangspunkt, um mit der Erkundung zu beginnen, da viele systemd-analyze Werkzeugfunktionen sind auf den Start ausgerichtet. Aber zuerst ist es wichtig, den Unterschied zwischen Booten und Startup zu verstehen. Die Boot-Sequenz beginnt mit dem BIOS-Selbsttest beim Einschalten (POST) und endet, wenn der Kernel vollständig geladen ist und die Kontrolle über das Hostsystem übernimmt, was der Beginn des Startvorgangs und der Punkt ist, an dem das systemd-Journal beginnt.

Im zweiten Artikel dieser Reihe, Systemd beim Start unter Linux verstehen , bespreche ich den Start etwas detaillierter in Bezug darauf, was passiert und in welcher Reihenfolge. In diesem Artikel möchte ich die Startsequenz untersuchen, um zu sehen, wie viel Zeit für den Start benötigt wird und welche Aufgaben die meiste Zeit in Anspruch nehmen.

Die Ergebnisse, die ich unten zeige, stammen von meiner primären Workstation, was viel interessanter ist als die Ergebnisse einer virtuellen Maschine. Diese Workstation besteht aus einem ASUS TUF X299 Mark 2-Motherboard, einer Intel i9-7960X-CPU mit 16 Kernen und 32 CPUs (Threads) und 64 GB RAM. Einige der folgenden Befehle können von einem Nicht-Root-Benutzer ausgeführt werden, aber ich werde in diesem Artikel root verwenden, um zu verhindern, dass zwischen den Benutzern gewechselt werden muss.

Es gibt mehrere Möglichkeiten, die Startreihenfolge zu untersuchen. Die einfachste Form der systemd-analyze Der Befehl zeigt einen Überblick über die Zeit, die in jedem der Hauptabschnitte des Startvorgangs verbracht wird, dem Kernel-Startvorgang, dem Laden und Ausführen von initrd (d. h. anfängliche Ramdisk, ein temporäres Systemabbild, das verwendet wird, um Hardware zu initialisieren und die Datei / einzuhängen [root]-Dateisystem) und Userspace (wo alle Programme und Daemons geladen werden, die erforderlich sind, um den Host in einen nutzbaren Zustand zu versetzen). Wenn kein Unterbefehl an den Befehl übergeben wird, systemd-analyze time wird impliziert:

[root@david ~]$ systemd-analyze 

Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s 

graphical.target reached after 10.071s in userspace

[root@david ~]#

Die bemerkenswertesten Daten in dieser Ausgabe sind die in der Firmware (BIOS) verbrachte Zeit:fast 54 Sekunden. Dies ist eine außerordentlich lange Zeit, und keines meiner anderen physischen Systeme braucht auch nur annähernd so lange, um durch das BIOS zu kommen.

Mein System76 Oryx Pro-Laptop verbringt nur 8,506 Sekunden im BIOS, und alle meine selbstgebauten Systeme brauchen etwas weniger als 10 Sekunden. Nach einigen Online-Suchen fand ich heraus, dass dieses Motherboard für seine übermäßig lange BIOS-Startzeit bekannt ist. Mein Motherboard "bootet" nie einfach. Es hängt immer, und ich muss einen Ein-/Ausschaltzyklus durchführen, und dann startet das BIOS mit einem Fehler, und ich muss F1 drücken, um die BIOS-Konfiguration aufzurufen, von wo aus ich das Startlaufwerk auswählen und den Startvorgang beenden kann. Hier kommt die zusätzliche Zeit her.

Nicht alle Hosts zeigen Firmware-Daten an. Meine unwissenschaftlichen Experimente lassen mich glauben, dass diese Daten nur für Intel-Prozessoren der Generation 9 oder höher angezeigt werden. Aber das könnte falsch sein.

Dieser Überblick über den Boot-Startprozess ist interessant und bietet gute (wenn auch begrenzte) Informationen, aber es gibt viel mehr Informationen über den Start, wie ich weiter unten beschreiben werde.

Schuld zuweisen

Sie können systemd-analyze blame verwenden um herauszufinden, welche systemd-Einheiten die meiste Zeit zum Initialisieren benötigen. Die Ergebnisse werden in der Reihenfolge der Zeit angezeigt, die sie für die Initialisierung benötigen, von der höchsten zur niedrigsten:

[root@david ~]$ systemd-analyze blame                                                                         

       5.417s NetworkManager-wait-online.service                                                       

       3.423s dracut-initqueue.service                                                                 

       2.715s systemd-udev-settle.service                                                              

       2.519s fstrim.service                                                                           

       1.275s udisks2.service                                                                          

       1.271s smartd.service                                                                           

        996ms upower.service                                                                           

        637ms lvm2-monitor.service                                                                     

        533ms lvm2-pvscan@8:17.service                                                                 

        520ms dmraid-activation.service                                                                

        460ms vboxdrv.service                                                                          

        396ms initrd-switch-root.service

<SNIP – removed lots of entries with increasingly small times>

Da viele dieser Dienste parallel starten, können sich die Zahlen zu erheblich mehr als der durch systemd-analyze time angegebenen Summe summieren für alles nach dem BIOS. All dies sind kleine Zahlen, daher kann ich hier keine signifikanten Einsparungen finden.

Die Daten aus diesem Befehl können Hinweise darauf geben, welche Dienste Sie in Betracht ziehen könnten, um die Startzeiten zu verbessern. Nicht verwendete Dienste können deaktiviert werden. Es scheint keinen einzelnen Dienst zu geben, der während dieser Startsequenz übermäßig lange dauert. Möglicherweise sehen Sie bei jedem Booten und Start unterschiedliche Ergebnisse.

Kritische Ketten

Wie der kritische Pfad im Projektmanagement, eine kritische Kette zeigt die zeitkritische Kette von Ereignissen, die während des Startvorgangs stattfinden. Dies sind die systemd-Einheiten, die Sie sich ansehen sollten, wenn der Start langsam ist, da sie diejenigen sind, die Verzögerungen verursachen würden. Dieses Tool zeigt nicht alle Einheiten an, die starten, sondern nur die in dieser kritischen Ereigniskette:

[root@david ~]# systemd-analyze critical-chain 

The time when unit became active or started is printed after the "@" character.

The time the unit took to start is printed after the "+" character.



graphical.target @10.071s

└─lxdm.service @10.071s

  └─plymouth-quit.service @10.047s +22ms

    └─systemd-user-sessions.service @10.031s +7ms

      └─remote-fs.target @10.026s

        └─remote-fs-pre.target @10.025s

          └─nfs-client.target @4.636s

            └─gssproxy.service @4.607s +28ms

              └─network.target @4.604s

                └─NetworkManager.service @4.383s +219ms

                  └─dbus-broker.service @4.434s +136ms

                    └─dbus.socket @4.369s

                      └─sysinit.target @4.354s

                        └─systemd-update-utmp.service @4.345s +9ms

                          └─auditd.service @4.301s +42ms

                            └─systemd-tmpfiles-setup.service @4.254s +42ms

                              └─import-state.service @4.233s +19ms

                                └─local-fs.target @4.229s

                                  └─Virtual.mount @4.019s +209ms

                                    └─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms

                                      └─local-fs-pre.target @3.726s

                                        └─lvm2-monitor.service @356ms +637ms

                                          └─dm-event.socket @319ms

                                            └─-.mount

                                              └─system.slice

                                                └─-.slice

[root@david ~]#

Den Zahlen ist @ vorangestellt zeigen die absolute Anzahl von Sekunden seit Beginn des Startvorgangs, wenn das Gerät aktiv wird. Die Zahlen mit vorangestelltem + zeigt an, wie lange es dauert, bis das Gerät startet.

Systemstatus

Manchmal müssen Sie den aktuellen Zustand des Systems ermitteln. Der systemd-analyze dump Befehl gibt eine massive aus Datenmenge über den aktuellen Systemzustand. Es beginnt mit einer Liste der primären Boot-Zeitstempel, einer Liste jeder systemd-Einheit und einer vollständigen Beschreibung des Zustands jeder:

[root@david ~]# systemd-analyze dump

Timestamp firmware: 1min 7.983523s

Timestamp loader: 3.872325s

Timestamp kernel: Wed 2020-08-26 12:33:35 EDT

Timestamp initrd: Wed 2020-08-26 12:33:38 EDT

Timestamp userspace: Wed 2020-08-26 12:33:42 EDT

Timestamp finish: Wed 2020-08-26 16:33:56 EDT

Timestamp security-start: Wed 2020-08-26 12:33:42 EDT

Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT

Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT

Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT

Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT

Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT

Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT

Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT

Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT

Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT

Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT

Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT

-> Unit system.slice:

        Description: System Slice

        Instance: n/a

        Unit Load State: loaded

        Unit Active State: active

        State Change Timestamp: Wed 2020-08-26 12:33:38 EDT

        Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT

        Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT

        Active Exit Timestamp: n/a

        Inactive Enter Timestamp: n/a

        May GC: no

<SNIP – Deleted a bazillion lines of output>

Auf meiner Haupt-Workstation erzeugte dieser Befehl einen Stream von 49.680 Zeilen und etwa 1,66 MB. Dieser Befehl ist sehr schnell, sodass Sie nicht auf die Ergebnisse warten müssen.

Weitere Linux-Ressourcen

• Spickzettel für Linux-Befehle
• Spickzettel für fortgeschrittene Linux-Befehle
• Kostenloser Online-Kurs:RHEL Technical Overview
• Spickzettel für Linux-Netzwerke
• SELinux-Spickzettel
• Spickzettel für allgemeine Linux-Befehle
• Was sind Linux-Container?
• Unsere neuesten Linux-Artikel

Ich mag den Detailreichtum der verschiedenen angeschlossenen Geräte, wie z. B. Speicher. Jede systemd-Unit hat einen Abschnitt mit Details wie Modi für verschiedene Laufzeiten, Cache- und Protokollverzeichnisse, die zum Starten der Unit verwendete Befehlszeile, die Prozess-ID (PID), den Startzeitstempel sowie Speicher- und Dateilimits.

Die Manpage für systemd-analyze zeigt den systemd-analyze --user dump Option, die Informationen über den internen Zustand der Benutzerverwaltung anzeigen soll. Dies schlägt bei mir fehl, und Internetrecherchen weisen darauf hin, dass möglicherweise ein Problem damit vorliegt. In systemd --user Instanzen werden verwendet, um die Ressourcen für die Hierarchie von Prozessen zu verwalten und zu steuern, die jedem Benutzer gehören. Die Prozesse für jeden Benutzer sind Teil einer Kontrollgruppe, die ich in einem zukünftigen Artikel behandeln werde.

Analytics-Grafiken

Die meisten spitzenhaarigen Chefs (PHBs) und viele gute Manager finden hübsche Diagramme einfacher zu lesen und zu verstehen als die textbasierten Systemleistungsdaten, die ich normalerweise bevorzuge. Manchmal mag sogar ich ein gutes Diagramm und systemd-analyze bietet die Möglichkeit, Boot-/Startdaten in einem SVG-Vektorgrafikdiagramm anzuzeigen.

Der folgende Befehl generiert eine Vektorgrafikdatei, die die Ereignisse anzeigt, die während des Bootens und Hochfahrens stattfinden. Das Generieren dieser Datei dauert nur wenige Sekunden:

[root@david ~]# systemd-analyze plot > /tmp/bootup.svg

Dieser Befehl erstellt eine SVG, eine Textdatei, die eine Reihe von Grafikvektoren definiert, die von Anwendungen wie Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw und anderen zum Erstellen eines Diagramms verwendet werden. Diese Anwendungen verarbeiten SVG-Dateien, um ein Bild zu erstellen.

Ich habe LibreOffice Draw verwendet, um ein Diagramm zu rendern. Das Diagramm ist riesig, und Sie müssen erheblich hineinzoomen, um Details zu erkennen. Hier ist ein kleiner Teil davon:

Die Startsequenz befindet sich links von der Null (0) auf der Zeitachse im Diagramm, und die Startsequenz befindet sich rechts von Null. Dieser kleine Teil zeigt den Kernel, initrd , und die Prozesse initrd gestartet.

Diese Grafik zeigt auf einen Blick, was wann gestartet wurde, wie lange der Start gedauert hat und welche großen Abhängigkeiten es gibt. Der kritische Pfad ist rot hervorgehoben.

Ein weiterer Befehl, der eine grafische Ausgabe erzeugt, ist systemd-analyze plot . Es generiert textuelle Beschreibungen von Abhängigkeitsgraphen im DOT-Format. Der resultierende Datenstrom wird dann durch den dot geleitet Dienstprogramm, das Teil einer Familie von Programmen ist, mit denen Vektorgrafikdateien aus verschiedenen Datentypen erstellt werden können. Diese SVG-Dateien können auch von den oben aufgeführten Tools verarbeitet werden.

Generieren Sie zunächst die Datei. Auf meiner primären Workstation dauerte dies fast neun Minuten:

[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg

   Color legend: black     = Requires

                 dark blue = Requisite

                 dark grey = Wants

                 red       = Conflicts

                 green     = After



real    8m37.544s

user    8m35.375s

sys     0m0.070s

[root@david ~]#

Ich werde die Ausgabe hier nicht reproduzieren, da das resultierende Diagramm ziemlich Spaghetti ist. Aber Sie sollten es versuchen und sich das Ergebnis ansehen, um zu sehen, was ich meine.

Bedingungen

Eine der interessanteren, aber etwas generischen Fähigkeiten, die ich beim Lesen von systemd-analyze(1) entdeckt habe Manpage ist die condition Unterbefehl. (Ja – ich lese die Manpages und es ist erstaunlich, was ich auf diese Weise gelernt habe!) Diese condition Der Unterbefehl kann verwendet werden, um die Bedingungen und Behauptungen zu testen, die in systemd-Unit-Dateien verwendet werden können.

Es kann auch in Skripten verwendet werden, um eine oder mehrere Bedingungen auszuwerten – es gibt eine Null (0) zurück, wenn alle erfüllt sind, oder eine Eins (1), wenn eine Bedingung nicht erfüllt ist. In beiden Fällen spuckt es auch Text über seine Ergebnisse aus.

Das folgende Beispiel aus der Manpage ist etwas komplex. Es testet auf eine Kernel-Version zwischen 4.0 und 5.1, dass der Host mit Wechselstrom betrieben wird, dass die Systemarchitektur alles andere als ARM ist und dass das Verzeichnis /etc/os-release existiert. Ich habe das echo $? hinzugefügt Anweisung zum Drucken des Rückgabecodes.

[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \

                    'ConditionKernelVersion = >=5.1' \

                    'ConditionACPower=|false' \

                    'ConditionArchitecture=|!arm' \

                    'AssertPathExists=/etc/os-release' ; \

echo $?

test.service: AssertPathExists=/etc/os-release succeeded.

Asserts succeeded.

test.service: ConditionArchitecture=|!arm succeeded.

test.service: ConditionACPower=|false failed.

test.service: ConditionKernelVersion=>=5.1 succeeded.

test.service: ConditionKernelVersion=!<4.0 succeeded.

Conditions succeeded.

0

[root@david ~]#

Die Liste der Bedingungen und Assertionen beginnt ungefähr bei Zeile 600 in systemd.unit(5) Manpage.

Konfigurationsdateien auflisten

Die systemd-analyze bietet eine Möglichkeit, den Inhalt verschiedener Konfigurationsdateien an STDOUT zu senden , wie hier gezeigt. Das Basisverzeichnis ist /etc/ :

[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service

# /etc/systemd/system/display-manager.service

[Unit]

Description=LXDM (Lightweight X11 Display Manager)

#Documentation=man:lxdm(8)

[email protected]

After=systemd-user-sessions.service [email protected] plymouth-quit.service livesys-late.service

#Conflicts=plymouth-quit.service



[Service]

ExecStart=/usr/sbin/lxdm

Restart=always

IgnoreSIGPIPE=no

#BusName=org.freedesktop.lxdm



[Install]

Alias=display-manager.service

[root@david ~]#

Das ist eine Menge Tipparbeit, um nicht mehr als eine Standard-cat zu tun Befehl tut. Ich finde den nächsten Befehl ein kleines bisschen hilfreich. Es kann Dateien mit dem angegebenen Muster innerhalb der standardmäßigen systemd-Speicherorte suchen:

[root@david ~]# systemctl cat backup*

# /etc/systemd/system/backup.timer

# This timer unit runs the local backup program

# (C) David Both

# Licensed under GPL V2

#



[Unit]

Description=Perform system backups

Requires=backup.service



[Timer]

Unit=backup.service

OnCalendar=*-*-* 00:15:30



[Install]

WantedBy=timers.target





# /etc/systemd/system/backup.service

# This service unit runs the rsbu backup program

# By David Both

# Licensed under GPL V2

#



[Unit]

Description=Backup services using rsbu

Wants=backup.timer



[Service]

Type=oneshot

Environment="HOME=/root"

ExecStart=/usr/local/bin/rsbu -bvd1

ExecStart=/usr/local/bin/rsbu -buvd2



[Install]

WantedBy=multi-user.target



[root@david ~]#

Beide Befehle stellen dem Inhalt jeder Datei eine Kommentarzeile voran, die den vollständigen Pfad und Namen der Datei enthält.

Verifizierung der Unit-Datei

Nachdem Sie eine neue Unit-Datei erstellt haben, kann es hilfreich sein, zu überprüfen, ob ihre Syntax korrekt ist. Dies ist, was die verify Unterbefehl tut. Es kann Anweisungen auflisten, die falsch geschrieben sind, und fehlende Serviceeinheiten aufrufen:

[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.service

Gemäß der Unix/Linux-Philosophie „Schweigen ist Gold“ bedeutet ein Fehlen von Ausgabemeldungen, dass die gescannte Datei keine Fehler enthält.

Sicherheit

Die security Der Unterbefehl überprüft die Sicherheitsstufe bestimmter Dienste. Es funktioniert nur mit Service-Units und nicht mit anderen Arten von Unit-Dateien:

[root@david ~]# systemd-analyze security display-manager 

  NAME                                                        DESCRIPTION                                                     >

✗ PrivateNetwork=                                             Service has access to the host's network                        >

✗ User=/DynamicUser=                                          Service runs as root user                                       >

✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)                Service may change UID/GID identities/capabilities              >

✗ CapabilityBoundingSet=~CAP_SYS_ADMIN                        Service has administrator privileges                            >

✗ CapabilityBoundingSet=~CAP_SYS_PTRACE                       Service has ptrace() debugging abilities                        >

✗ RestrictAddressFamilies=~AF_(INET|INET6)                    Service may allocate Internet sockets                           >

✗ RestrictNamespaces=~CLONE_NEWUSER                           Service may create user namespaces                              >

✗ RestrictAddressFamilies=~…                                  Service may allocate exotic sockets                             >

✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP)           Service may change file ownership/access mode/capabilities unres>

✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER)         Service may override UNIX file/IPC permission checks            >

✗ CapabilityBoundingSet=~CAP_NET_ADMIN                        Service has network configuration privileges                    >

✗ CapabilityBoundingSet=~CAP_SYS_MODULE                       Service may load kernel modules

<SNIP>

✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG                   Service may issue vhangup()                                     >

✗ CapabilityBoundingSet=~CAP_WAKE_ALARM                       Service may program timers that wake up the system              >

✗ RestrictAddressFamilies=~AF_UNIX                            Service may allocate local sockets                              >



→ Overall exposure level for backup.service: 9.6 UNSAFE ?

lines 34-81/81 (END)

Ja, das Emoji ist Teil der Ausgabe. Aber natürlich brauchen viele Dienste einen ziemlich vollständigen Zugriff auf alles, um ihre Arbeit zu erledigen. Ich habe dieses Programm mit mehreren Diensten ausgeführt, einschließlich meines eigenen Backup-Dienstes; Die Ergebnisse können unterschiedlich sein, aber das Endergebnis scheint größtenteils gleich zu sein.

Dieses Tool wäre sehr nützlich, um Userspace-Serviceeinheiten in sicherheitskritischen Umgebungen zu überprüfen und zu reparieren. Ich glaube nicht, dass es für die meisten von uns viel zu bieten hat.

Abschließende Gedanken

Dieses leistungsstarke Tool bietet einige interessante und erstaunlich nützliche Optionen. Vieles, was in diesem Artikel untersucht wird, dreht sich um die Verwendung von systemd-analyze um Einblicke in die Startleistung von Linux mit systemd zu geben. Es kann auch andere Aspekte von systemd analysieren.

Einige dieser Tools sind von begrenztem Nutzen, und einige sollten vollständig vergessen werden. Aber die meisten können effektiv verwendet werden, wenn Probleme mit Start- und anderen systemd-Funktionen gelöst werden.

Ressourcen

Es gibt eine Menge Informationen über systemd im Internet, aber vieles ist knapp, stumpf oder sogar irreführend. Zusätzlich zu den in diesem Artikel erwähnten Ressourcen bieten die folgenden Webseiten detailliertere und zuverlässigere Informationen zum Systemstart. Diese Liste ist seit dem Beginn dieser Artikelserie gewachsen, um die von mir durchgeführte Forschung widerzuspiegeln.

• Die Handbuchseite systemd.unit(5) enthält eine schöne Liste von Unit-Dateiabschnitten und ihren Konfigurationsoptionen zusammen mit kurzen Beschreibungen von jedem.
• Das Fedora-Projekt hat eine gute, praktische Anleitung zu systemd. Es enthält so ziemlich alles, was Sie wissen müssen, um einen Fedora-Computer mit systemd zu konfigurieren, zu verwalten und zu warten.
• Das Fedora-Projekt hat auch einen guten Spickzettel, der die alten SystemV-Befehle mit vergleichbaren Systemd-Befehlen vergleicht.
• Die Red Hat Dokumentation enthält eine gute Beschreibung der Unit-Dateistruktur sowie andere wichtige Informationen.
• Detaillierte technische Informationen über systemd und die Gründe für seine Erstellung finden Sie in der Beschreibung von systemd auf Freedesktop.org.
• Linux.com's "More systemd fun" bietet weiterführende Informationen und Tipps zu systemd.

Es gibt auch eine Reihe von sehr technischen Artikeln für Linux-Systemadministratoren von Lennart Poettering, dem Designer und Hauptentwickler von systemd. Diese Artikel wurden zwischen April 2010 und September 2011 geschrieben, sind aber heute genauso aktuell wie damals. Vieles von allem anderen Guten, das über systemd und sein Ökosystem geschrieben wurde, basiert auf diesen Papieren.

• Überdenken von PID 1
• systemd für Administratoren, Teil I
• systemd für Administratoren, Teil II
• systemd für Administratoren, Teil III
• systemd für Administratoren, Teil IV
• systemd für Administratoren, Teil V
• systemd für Administratoren, Teil VI
• systemd für Administratoren, Teil VII
• systemd für Administratoren, Teil VIII
• systemd für Administratoren, Teil IX
• systemd für Administratoren, Teil X
• systemd für Administratoren, Teil XI