Kapitel 3. Die Systeminitialisierung

Inhaltsverzeichnis

3.1. Ein Überblick über den Bootstrap-Prozess
3.1.1. Stufe 1: das BIOS
3.1.2. Stufe 2: der Bootloader
3.1.3. Stufe 3: das Mini-Debian-System
3.1.4. Stufe 4: das normale Debian-System
3.2. Systemd-Init
3.2.1. Der Rechnername
3.2.2. Das Dateisystem
3.2.3. Initialisierung der Netzwerkschnittstellen
3.2.4. Die Kernel-Meldungen
3.2.5. Die Systemmeldungen
3.2.6. Systemmanagement unter systemd
3.2.7. Anpassen von systemd
3.3. Das udev-System
3.3.1. Die Kernel-Modul-Initialisierung

Als Systemadministrator sollten Sie grob wissen, wie das Debian-System gestartet und konfiguriert wird. Obwohl die genauen Details in den Quelldateien der installierten Pakete und deren Dokumentation zu finden sind, ist dies für die meisten von uns ein bisschen viel.

Ich habe mein bestes gegeben, um einen schnellen Überblick über die wichtigsten Themen des Debian-Systems und dessen Konfiguration als Referenz für Sie bereitzustellen, basierend auf aktuellem und früherem Wissen von mir und anderen. Da das Debian-System sich ständig verändert, könnte sich die Situation teilweise verändert haben. Bevor Sie irgendwelche Änderungen an dem System vornehmen, sollten Sie die aktuellste Dokumentation der jeweiligen Pakete zu Rate ziehen.

[Tipp] Tipp

bootup(7) beschreibt den System-Boot-Prozess basierend auf systemd (derzeitiges Debian-System).

[Tipp] Tipp

boot(7) beschreibt den System-Boot-Prozess basierend auf UNIX System V Release 4 (älteres Debian-System).

Das Computer-System durchläuft verschiedene Phasen des Bootstrap-Prozesses vom Einschalten bis zur Bereitstellung des funktionalen Betriebssystems an den Benutzer.

Der Einfachheit halber beschränke ich meine Betrachtung auf die weit verbreitete PC-Plattform mit einer Standardinstallation.

Der typische Bootstrap-Prozess ist wie eine 4-stufige Rakete. Jede Stufe übergibt die Systemkontrolle an die jeweils nachfolgende Stufe:

Natürlich können diese unterschiedlich konfiguriert werden. Wenn Sie zum Beispiel Ihren eigenen Kernel kompilieren, werden Sie unter Umständen den Schritt mit dem Mini-Debian-System überspringen. Gehen Sie daher nicht davon aus, dass dies alles in Ihrem Fall zutrifft, solange Sie es nicht selbst überprüft haben.

[Anmerkung] Anmerkung

Bei ungewöhnlichen Computer-Plattformen wie dem SUN- oder dem Macintosh-System könnten das BIOS im ROM und die Partitionen auf der Festplatte sich stark von dem hier beschriebenen unterscheiden (Abschnitt 9.5.2, „Konfiguration der Plattenpartitionen“). Bitte suchen Sie in solch einem Fall an anderer Stelle nach Plattform-spezifischer Dokumentation.

Das BIOS ist die erste Stufe des Boot-Prozesses und wird durch das Einschalten des Rechners aufgerufen. Es liegt im Nur-Lese-Speicher (read only memory/ROM) und wird von einer speziellen Speicheradresse ausgeführt, auf die die CPU durch den Einschaltvorgang verwiesen wird.

Das BIOS führt die grundsätzliche Initialisierung der Hardware durch (POST: power on self test / Selbsttest nach dem Einschalten) und übergibt die Systemkontrolle an die nächste Stufe. Das BIOS wird üblicherweise mit der Hardware geliefert.

Im BIOS-Startbildschirm wird für gewöhnlich angezeigt, welche Taste(n) Sie drücken müssen, um das BIOS-Setup zu erreichen, in dem das Verhalten des BIOS konfiguriert werden kann. Typisch hierfür sind F1, F2, F10, Esc, Einfg und Entf. Wenn Ihr BIOS-Startbildschirm durch eine hübsche grafische Anzeige versteckt wird, müssen Sie eventuell eine oder mehrere Tasten wie z.B. Esc drücken, um diese Grafik auszublenden. Die hierzu benötigten Tasten sind je nach Hardware sehr unterschiedlich.

Die Hardware und die Reihenfolge des Codes, der durch das BIOS gestartet wird, kann über das BIOS-Setup ausgewählt werden. Typischerweise werden die ersten paar Sektoren des ersten gefundenen, vorgewählten Gerätes (Festplatte, Diskette, CD-ROM, …) in den Speicher geladen und dieser initiale Code wird dann ausgeführt. Das kann folgendes sein:

  • ein Bootloader-Code;

  • der Kernel-Code eines Ursprungs-Betriebssystems wie z.B. FreeDOS;

  • der Kernel-Code des Ziel-Betriebssystems, falls er in diesen kleinen Speicherbereich passt.

Gewöhnlich wird das System von der angegebenen Partition der primären Festplatte gestartet. Die ersten zwei Sektoren der Festplatte enthalten auf normalen PC-Systemen den Master Boot Record (MBR). Die Partitionsinformationen inklusive der Boot-Auswahl sind am Ende des MBR gespeichert. Der in der ersten Stufe vom BIOS ausgeführte Bootloader-Code liegt im Rest des MBR.

Der Bootloader ist die zweite Stufe des Boot-Prozesses und wird durch das BIOS gestartet. Er lädt das System-Kernel-Image und das initrd-Image in den Speicher und übergibt diesen die Kontrolle. Das initrd-Image ist ein Abbild des Wurzeldateisystems und seine Unterstützung hängt von dem verwendeten Bootloader ab.

Das Debian-System nutzt normalerweise den Linux-Kernel als Standard-System-Kernel. Das initrd-Image des aktuellen 2.6/3.x-Linux-Kernels ist technisch gesehen ein initramfs-Image (initial RAM filesystem). Das Basis-initrd-Image ist ein komprimiertes cpio-Archiv der Dateien im Wurzeldateisystem. Der Kernel kann sehr früh im Boot-Prozess (bevor dieses initrd-Image geladen wird) ein Update des Microcodes durchführen. Dies wird ermöglicht durch das kombinierte initrd-Image, das aus dem Binär-Blob des Microcodes und dem daran angehängten Basis-initrd-Image besteht.

[Tipp] Tipp

Sie können den Inhalt der initrd-Image-Datei mittels lsinitramfs(8) und unmkinitramfs(8) aus dem Paket initramfs-tools-core untersuchen. Details finden Sie unter https://wiki.debian.org/initramfs.

Eine Standardinstallation des Debian-Systems auf der PC-Plattform legt den ersten Teil des GRUB-Bootloaders (stage 1) im MBR ab. Es sind allerdings viele weitere Bootloader und Konfigurationsoptionen verfügbar.


[Warnung] Warnung

Spielen Sie nicht mit Bootloadern herum, ohne boot-fähige Rettungsmedien (USB-Stick, CD, Diskette) zur Hand zu haben, die von Images im grub-rescue-pc-Paket erstellt wurden. Damit können Sie Ihr System auch ohne funktionsfähigen Bootloader auf der Festplatte starten.

Bei GRUB Legacy ist die Datei zur Konfiguration des Menüs unter "/boot/grub/menu.lst" abgelegt. Sie enthält zum Beispiel Einträge wie den folgenden:

title           Debian GNU/Linux
root            (hd0,2)
kernel          /vmlinuz root=/dev/hda3 ro
initrd          /initrd.img

Bei GRUB 2 ist die Datei zur Konfiguration des Menüs unter "/boot/grub/grub.cfg" gespeichert. Sie wird automatisch durch "/usr/sbin/update-grub" unter Verwendung von Vorlagen aus "/etc/grub.d/*" und Einstellungen aus "/etc/default/grub" erzeugt. Die Einträge sehen aus wie folgt:

menuentry "Debian GNU/Linux" {
        set root=(hd0,3)
        linux /vmlinuz root=/dev/hda3
        initrd /initrd.img
}

Die GRUB-Parameter in diesen Beispielen haben folgende Bedeutungen:


[Anmerkung] Anmerkung

Der Wert der Partitionsnummer, wie er von GRUB Legacy verwendet wird, ist um 1 kleiner als der normal durch den Linux-Kernel und andere Werkzeuge genutzte. Das GRUB-2-Programm behebt dieses Problem.

[Tipp] Tipp

Die UUID-Kennung (lesen Sie dazu Abschnitt 9.5.3, „Zugriff auf Partitionen über die UUID-Kennung“) kann statt dem Gerätenamen (z.B. "/dev/hda3") genutzt werden, um ein block-orientiertes Gerät eindeutig zu identifizieren, z.B. mittels "root=UUID=81b289d5-4341-4003-9602-e254a17ac232 ro".

[Tipp] Tipp

Bei der Nutzung von GRUB sind die Kernel-Boot-Parameter in /boot/grub/grub.cfg festgelegt. Auf Debian-Systemen sollten Sie /boot/grub/grub.cfg jedoch nicht direkt verändern. Ändern Sie stattdessen den GRUB_CMDLINE_LINUX_DEFAULT-Wert in /etc/default/grub und führen Sie dann update-grub(8) aus, um /boot/grub/grub.cfg zu aktualisieren.

[Tipp] Tipp

Sie können über einen Bootloader einen weiteren Bootloader starten, diese Technik nennt man Chain loading.

Weitere Infos finden Sie unter "info grub" und grub-install(8).

Das Mini-Debian-System ist die dritte Stufe des Boot-Prozesses und wird durch den Bootloader gestartet. Es lässt den System-Kernel mit seinem eigenen Wurzeldateisystem im Speicher laufen. Dies ist ein optionaler, vorbereitender Schritt des Boot-Prozesses.

[Anmerkung] Anmerkung

Der Begriff "Mini-Debian-System" wurde von dem Autor erfunden, um diese dritte Stufe des Boot-Prozesses in diesem Dokument zu beschreiben. Dieses System wird normalerweise initrd- oder initramfs-System genannt. Ein ähnliches System wird im Speicher auch durch den Debian Installer verwendet.

"/init" wird als erstes Programm aus diesem Wurzeldateisystem im Speicher ausgeführt. Es ist ein Programm, das den Kernel im Userspace initialisiert und die Kontrolle an die nächste Stufe übergibt. Dieses Mini-Debian-System bietet Flexibilität für den Boot-Prozess, um zum Beispiel Kernel-Module vor dem Hauptteil des Boot-Prozesses hinzuzufügen oder um das Wurzeldateisystem als verschlüsseltes Dateisystem einzubinden.

  • "/init" ist ein Shell-Skript, wenn das initfamfs durch initramfs-tools erstellt wurde.

    • Sie können diesen Teil des Boot-Prozesses unterbrechen, um eine root-Shell zu bekommen, indem Sie "break=init" usw. zu den Kernel-Boot-Parametern hinzufügen. Informationen zu weiteren Unterbrechungsmöglichkeiten finden Sie im "/init"-Skript. Diese Shell-Umgebung ist ausgeklügelt genug, um eine gute Überprüfung der Hardware Ihrer Maschine zu ermöglichen.

    • Die verfügbaren Befehle in diesem Mini-Debian-System gehen auf ein GNU-Werkzeug namens busybox(1) zurück und werden auch hauptsächlich von diesem bereitgestellt.

  • "/init" ist ein binäres systemd-Programm, wenn das initramfs durch dracut erstellt wurde.

    • Befehle in diesem Mini-Debian-System sind in ihrer Funktionalität auf die systemd(1)-Umgebung reduziert.

[Achtung] Achtung

Sie müssen die Option "-n" für den mount-Befehl verwenden, wenn Sie sich im Nur-Lese-Wurzeldateisystem befinden.

Das normale Debian-System ist die vierte Stufe des Boot-Prozesses und wird von dem Mini-Debian-System gestartet. Der System-Kernel des Mini-Debian-Systems läuft in dieser Umgebung weiter. Das verwendete Wurzeldateisystem wird von dem im Arbeitsspeicher umgeschwenkt zu dem auf der echten Festplatte.

Das Programm init wird als erstes Programm mit PID=1 ausgeführt und erledigt die eigentliche Hauptarbeit beim Booten, das Starten verschiedener Programme. Der Standardpfad zum init-Programm ist "/sbin/init", aber er kann über einen Kernel-Boot-Parameter wie "init=/pfad/zum/init-programm" auch geändert werden.

Das Standard-Init-Programm hat sich im Laufe der Zeit verändert:

  • Vor Squeeze verwendete Debian das einfache SysV-artige Init.

  • Debian Wheezy verbesserte das SysV-ähnliche Init durch Sortierung der Boot-Reihenfolge mittels LSB-Header und parallelen Start der Boot-Skripte.

  • Debian Jessie schwenkt um auf systemd, ein ereignisbasiertes Init-System mit paralleler Initialisierung.

[Tipp] Tipp

Mittels "ps --pid 1 -f" können Sie überprüfen, welcher init-Befehl letztlich auf Ihrem System verwendet wird.

[Tipp] Tipp

"/sbin/init" wurde nach Debian Jessie ein symbolischer Link auf "/lib/systemd/systemd".

Tabelle 3.3. Liste von Boot-Hilfsprogrammen für das Debian-System

Paket Popcon Größe Beschreibung
systemd V:750, I:858 13484 Ereignis-basierter init(8)-Daemon für gleichzeitige Ausführung (Alternative zu sysvinit)
systemd-sysv V:733, I:852 122 die Handbuchseiten und Links, die nötig sind, um sysvinit durch systemd zu ersetzen
systemd-cron V:0, I:1 139 systemd-Units, um die Funktionalitäten des cron-Daemons sowie von anacron bereitzustellen
init-system-helpers V:745, I:876 133 Hilfsprogramme, um zwischen sysvinit und systemd umschalten zu können
initscripts V:188, I:509 213 Skripte zur Initialisierung und zum Herunterfahren des Systems
sysvinit-core V:10, I:13 263 System-V-ähnliche init(8)-Werkzeuge
sysv-rc V:334, I:520 121 System-V-ähnlicher Mechanismus zum Wechsel des Runlevels
sysvinit-utils V:729, I:999 131 System-V-ähnliche Werkzeuge (startpar(8), bootlogd(8), …)
lsb-base V:886, I:999 49 Zur Linux Standard Base 3.2 konforme init-Skript-Funktionalität
insserv V:403, I:510 148 Werkzeug, um die Boot-Reihenfolge unter Verwendung von LSB-konformen init.d-Skript-Abhängigkeiten zu organisieren
uswsusp V:5, I:10 714 Werkzeuge, um das durch Linux bereitgestellte Userspace-Software-Suspend zu verwenden
kexec-tools V:1, I:7 271 Werkzeug für kexec(8)-Neustarts (Warmstarts)
systemd-bootchart V:0, I:0 123 Performance-Analyseprogramm für den Boot-Prozess
bootchart2 V:0, I:1 94 Performance-Analyseprogramm für den Boot-Prozess
pybootchartgui V:0, I:1 177 Performance-Analyseprogramm für den Boot-Prozess (Visualisierung)
mingetty V:0, I:3 35 getty(8) nur für die Konsole
mgetty V:0, I:1 319 Intelligenter getty(8)-Ersatz für Modems

[Tipp] Tipp

Unter Debian Wiki: BootProcessSpeedup finden Sie aktuelle Tipps zur Beschleunigung des Boot-Prozesses.

Dieser Abschnitt beschreibt, wie das System durch das systemd(1)-Programm mit der PID=1 (also dem init-Prozess) gestartet wird.

Der systemd-Init-Prozess wird - basierend auf den Unit-Konfigurationsdateien (siehe systemd.unit(5)) - in mehrere parallele Prozesse aufgespalten; diese Konfigurationsdateien sind in deklarativem Stil geschrieben, im Unterschied zu dem prozeduralen Stil von SysV. Diese können von einer Reihe von Dateisystempfaden geladen werden (siehe systemd-system.conf(5)), die hier aufgeführt sind:

  • "/lib/systemd/system": Standard-Konfigurationsdateien des Betriebssystems

  • "/etc/systemd/system": Konfigurationsdateien zur Systemadministration, welche die Standard-Konfigurationsdateien des Betriebssystems überschreiben

  • "/run/systemd/system": zur Laufzeit generierte Konfigurationsdateien, welche die fest installierten Konfigurationsdateien überschreiben

Deren Abhängigkeiten untereinander sind durch die Regeln "Wants=", "Requires=", "Before=", "After=", … (siehe "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in systemd.unit(5)) definiert. Die Ressourcen-Steuerung ist ebenfalls festgelegt (siehe systemd.resource-control(5)).

Die Endung der Unit-Konfigurationsdateien definiert ihren Typ wie folgt:

  • *.service beschreibt einen Prozess (Dienst), der von systemd gesteuert und überwacht wird. Siehe systemd.service(5).

  • *.device beschreibt ein Gerät, das im sysfs(5) als udev(7)-Gerätedatei abgebildet ist. Siehe systemd.device(5).

  • *.mount beschreibt einen Einbindungspunkt im System, der von systemd gesteuert und überwacht wird. Siehe systemd.mount(5).

  • *.automount beschreibt einen automatischen Einbindungspunkt im System, der von systemd gesteuert und überwacht wird. Siehe systemd.automount(5).

  • *.swap beschreibt ein Swap-Device oder eine Swap-Datei (zum Auslagern von Arbeitsspeicher auf eine Festplatte), die von systemd gesteuert und überwacht wird. Siehe systemd.swap(5).

  • *.path beschreibt einen Pfad im Dateisystem, der von systemd zum Zwecke der pfad-basierten Aktivierung überwacht wird. Siehe systemd.path(5).

  • *.socket beschreibt einen Socket, der von systemd zum Zwecke der socket-basierten Aktivierung gesteuert und überwacht wird. Siehe systemd.socket(5).

  • *.timer beschreibt einen Timer (Zeitgeber), der von systemd zum Zwecker der timer-basierten Aktivierung gesteuert und überwacht wird. Siehe systemd.timer(5).

  • *.slice verwaltet Ressourcen über cgroups(7). Siehe systemd.slice(5).

  • *.scope wird programmgesteuert über die Busschnittstellen von systemd erzeugt, um Systemprozesse zu verwalten. Siehe systemd.scope(5).

  • *.target fasst andere Unit-Konfigurationsdateien zu Gruppen zusammen, um Synchronisierungspunkte für den Startprozess zu erstellen. Siehe systemd.target(5).

Während des Systemstarts versucht der systemd-Prozess, das Target "/lib/systemd/system/default.target (normalerweise ein symbolischer Link auf "graphical.target") zu starten. Als erstes werden dabei einige spezielle Target-Units (siehe systemd.special(7)) wie "local-fs.target", "swap.target" und "cryptsetup.target" aktiviert, um die Dateisysteme einzubinden. Dann werden über die Abhängigkeiten weitere Target-Units aktiviert. Details finden Sie in bootup(7).

systemd enthält Funktionalitäten, um die Rückwärtskompatibilität zu SysV zu gewährleisten. Boot-Skripte im SysV-Stil in "/etc/init.d/rc[0123456S].d/[KS]<name>" werden immer noch abgearbeitet, und telinit(8)-Befehle werden in Aktivierungsanforderungen für systemd-Units übersetzt.

[Achtung] Achtung

Die emulierten Runlevel 2 bis 4 verweisen über symbolische Links alle auf des gleiche "multi-user.target".

Die Optionen zum Einbinden normaler Festplatten- und Netzwerkdateisysteme werden in "/etc/fstab" festgelegt. See fstab(5) und Abschnitt 9.5.7, „Optimierung von Dateisystemen über mount-Optionen“.

Die Konfiguration verschlüsselter Dateisysteme ist in "/etc/crypttab" abgelegt. Siehe crypttab(5).

Software-RAID mit mdadm(8) wird in "/etc/mdadm/mdadm.conf" konfiguriert. Siehe mdadm.conf(5).

[Warnung] Warnung

Bei jedem Systemstart werden nach dem Einbinden aller Dateisysteme temporäre Dateien in "/tmp", "/var/lock" und "/var/run" gelöscht.

systemd bietet nicht nur das eigentliche init-System zum Starten des Systems, sondern auch Funktionalitäten zum Systemmanagement wie Logdateien, Anmeldedaten, Netzwerkverbindungen usw.

Das Systemmanagement unter systemd(1) läuft über eine Reihe von Befehlen:

  • der Befehl systemctl(1) steuert den System- und Dienste-Manager (für die Konsolenoberfläche, CLI);

  • der Befehl systemsdm(1) steuert den System- und Dienste-Manager (für die grafische Bedienoberfläche, GUI);

  • der Befehl journalctl(1) bedient Anfragen an das Journalsystem (Logdaten);

  • der Befehl loginctl(1) steuert den Anmeldemanager;

  • der Befehl systemd-analyze(1) analysiert die Performance beim Booten des Systems.

Hier eine Liste typischer systemd-Management-Befehle. Bezüglich der exakten Bedeutungen lesen Sie bitte die zugehörigen Handbuchseiten.

Tabelle 3.5. Liste typischer systemd-Management-Befehle

Tätigkeit Typ Befehl
grafische Oberfläche (GUI) für den Service-Manager GUI "systemadm" (aus dem systemd-ui-Paket)
Unit-Konfiguration aller Targets auflisten Unit "systemctl list-units --type=target"
Unit-Konfiguration aller Dienste (Services) auflisten Unit "systemctl list-units --type=service"
Typen aller Unit-Konfigurationen auflisten Unit "systemctl list-units --type=help"
Alle Socket-Units im Arbeitsspeicher auflisten Unit "systemctl list-sockets"
Alle Timer-Units im Arbeitsspeicher auflisten Unit "systemctl list-timers"
"$unit" starten Unit "systemctl start $unit"
"$unit" stoppen Unit "systemctl stop $unit"
Dienst-spezifische Konfiguration neu laden Unit "systemctl reload $unit"
"$unit" stoppen und neu starten Unit "systemctl restart $unit"
"$unit" starten und alle anderen stoppen Unit "systemctl isolate $unit"
Zur grafischen Oberfläche wechseln (GUI-System) Unit "systemctl isolate graphical"
Zur Konsolenoberfläche wechseln (Mehrbenutzer-CLI-System) Unit "systemctl isolate multi-user"
Zur Rettungssystem-Oberfläche wechseln (Einzelbenutzer-CLI-System) Unit "systemctl isolate rescue"
Kill-Signal an "$unit" senden Unit "systemctl kill $unit"
Prüfen, ob "$unit" aktiv ist Unit "systemctl is-active $unit"
Prüfen, ob "$unit" fehlgeschlagen ist Unit "systemctl is-failed $unit"
Status von "$unit|$PID|device" prüfen Unit "systemctl status $unit|$PID|$device"
Eigenschaften von "$unit|$job" anzeigen Unit "systemctl show $unit|$job"
Fehlgeschlagene "$unit" zurücksetzen (Reset) Unit "systemctl reset-failed $unit"
Abhängigkeiten aller Unit-Dienste auflisten Unit "systemctl list-dependencies --all"
Auf dem System installierte Unit-Dateien auflisten Unit-Datei "systemctl list-unit-files"
"$unit" aktivieren (symbolischen Link hinzufügen) Unit-Datei "systemctl enable $unit"
"$unit" deaktivieren (symbolischen Link entfernen) Unit-Datei "systemctl disable $unit"
"$unit" zum Starten bereit machen (symbolischen Link auf "/dev/null" entfernen) Unit-Datei "systemctl unmask $unit"
"$unit" am Starten hindern (symbolischen Link auf "/dev/null" hinzufügen) Unit-Datei "systemctl mask $unit"
Aktuelles default-Target abrufen Unit-Datei "systemctl get-default"
default-Target auf "graphical" setzen (grafische Oberfläche, GUI) Unit-Datei "systemctl set-default graphical"
default-Target auf "multi-user" setzen (Konsolenoberfläche, CLI) Unit-Datei "systemctl set-default multi-user"
Job-Umgebungseinstellungen anzeigen Umgebung "systemctl show-environment"
Job-Umgebungseinstellung "variable" auf "wert" setzen Umgebung "systemctl set-environment variable=wert"
Job-Umgebungseinstellung "variable" löschen Umgebung "systemctl unset-environment variable"
Alle Unit-Dateien und Daemons neu laden Betriebsdauer "systemctl daemon-reload"
System herunterfahren System "systemctl poweroff"
System herunterfahren und neu starten (Reboot) System "systemctl reboot"
System in Standby setzen (Suspend) System "systemctl suspend"
System in Ruhezustand setzen (Hibernate) System "systemctl hibernate"
Loginformationen von "$unit" anzeigen Journal "journalctl -u $unit"
Loginformationen von "$unit" anzeigen (Anzeige ähnlich wie "tail -f") Journal "journalctl -u $unit -f"
Dauer der einzelnen Initialisierungsschritte anzeigen Analyse "systemd-analyze time"
Alle Units auflisten, sortiert nach der Dauer ihrer Initialisierung Analyse "systemd-analyze blame"
"$unit"-Datei laden und auf Fehler prüfen Analyse "systemd-analyze verify $unit"
Boot-Prozess nachverfolgen über cgroups(7) Cgroup "systemd-cgls"
Boot-Prozess nachverfolgen über cgroups(7) Cgroup "ps xawf -eo pid,user,cgroup,args"
Boot-Prozess nachverfolgen über cgroups(7) Cgroup sysfs unter "/sys/fs/cgroup/systemd/" auslesen

In obigen Beispielen kann "$unit" für einen einzelnen Unit-Namen stehen (ein Anhang wie .service oder .target ist dabei optional), oder auch für die Angabe mehrerer Units (über Suchmuster im Shell-Stil wie "*", "?" oder "[]", die fnmatch(3) verwenden; diese werden auf die primären Namen aller Units angewandt, die derzeit in den Arbeitsspeicher geladen sind).

Befehlen zum Ändern des Systemstatus wird typischerweise ein "sudo" vorangestellt, um die nötigen administrativen Rechte anzufordern.

Die Ausgabe von "systemctl status $unit|$PID|$device" nutzt farbige Punkte ("●"), um den Unit-Status kompakt zusammenzufassen.

  • Ein weisser "●" steht für "inaktiv" oder "deaktiviert".

  • Ein roter "●" steht für "fehlgeschlagen" oder "Fehler".

  • Ein grüner "●" steht für "aktiv", "wird neu geladen" oder "wird aktiviert".

Bei einer Standardinstallation werden viele Netzwerkdienste (siehe Kapitel 6, Netzwerkapplikationen) von systemd durch network.target als Daemon-Prozess gestartet. "sshd" ist hier keine Ausnahme. Als Beispiel dafür, wie man so etwas anpassen kann, wollen wir zeigen, wie Sie "sshd" so ändern, dass er nur auf Anfrage (on-demand) startet.

Als erstes deaktivieren Sie die entsprechende Dienst-Unit:

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

Der klassische Weg zur on-demand-Aktivierung von Sockets führte früher über den indetd-Superserver. Unter systemd kann dies über das Hinzufügen von *.socket und *.service Unit-Konfigurationsdateien erreicht werden.

Eine sshd.socket anlegen zur Spezifizierung eines Sockets, der auf Anfragen überwacht wird:

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

Und eine sshd@.service als Dienste-Datei passend zu sshd.socket:

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

Dann muss der Dienst neu geladen werden:

 $ sudo systemctl daemon-reload

Für Linux-Kernel der 2.6-Reihe und neuer bietet das udev-System Mechanismen für automatische Hardware-Erkennung und -initialisierung (lesen Sie dazu udev(7)). Nach der Erkennung eines Gerätes durch den Kernel startet das udev-System einen User-Prozess. Dieser verwendet Informationen aus dem sysfs-Dateisystem (Näheres in Abschnitt 1.2.12, „procfs und sysfs“), lädt über den Befehl modprobe(8) benötigte Kernel-Module, die die Hardware unterstützen (Details in Abschnitt 3.3.1, „Die Kernel-Modul-Initialisierung“), und erstellt die zugehörigen Geräteknoten (device nodes).

[Tipp] Tipp

Falls "/lib/modules/<kernel-version>/modules.dep" mittels depmod(8) aus irgendeinem Grund nicht korrekt erstellt wurde, könnte es beim Laden der Module durch das udev-System Probleme geben. Führen Sie "depmod -a" aus, um dies zu beheben.

Die Namen der Geräteknoten können über udev-Regel-Dateien in "/etc/udev/rules.d/" konfiguriert werden. Aktuelle Standardregeln neigen dazu, dynamisch generierte Namen zu erzeugen, was (außer bei CD- und Netzwerkgeräten) dazu führt, dass sich die Gerätenamen von Mal zu Mal ändern. Indem Sie Ihre eigenen Regeln hinzufügen (ähnlich denen für CD- und Netzwerkgeräte), können Sie auch für andere Geräte wie z.B. USB-Memory-Sticks fest zugeordnete Gerätenamen vergeben. Lesen Sie dazu "Writing udev rules" oder "/usr/share/doc/udev/writing_udev_rules/index.html".

Da das udev-System immer ein wenig im Wandel ist, überlasse ich die Details anderen Dokumenten und beschränke mich hier auf das Nötigste.

[Tipp] Tipp

Für die Regeln zum Einbinden von Dateisystemen in "/etc/fstab" müssen Geräteknoten nicht fest zugeordnet sein. Sie können auch UUIDs verwenden, um Geräte einzubinden, statt der Gerätenamen wie "/dev/sda". Lesen Sie dazu Abschnitt 9.5.3, „Zugriff auf Partitionen über die UUID-Kennung“.

Das modprobe(8)-Programm erlaubt es, einen laufenden Linux-Kernel über einen User-Prozess zu konfigurieren, indem Kernel-Module hinzugefügt und entfernt werden. Das udev-System (Näheres in Abschnitt 3.3, „Das udev-System“) automatisiert dessen Aufruf, um bei der Initialisierung des Kernel-Moduls zu helfen.

Es gibt Module, die nicht zu bestimmter Hardware gehören, sowie spezielle Hardware-Treibermodule wie die folgenden, die im Voraus geladen werden müssen, indem Sie in die Datei "/etc/modules" eingetragen werden (Details in modules(5)):

Die Konfigurationsdateien für das modprobe(8)-Programm sind unterhalb des "/etc/modprobes.d/"-Verzeichnisses abgelegt, wie in modprobe.conf(5) beschrieben. (Falls Sie vermeiden möchten, dass einige Kernel-Module automatisch geladen werden, sollten Sie erwägen, diese in die Datei "/etc/modprobes.d/blacklist" einzutragen.)

Die Datei "/lib/modules/<version>/modules.dep" (erzeugt durch das Programm depmod(8)) beschreibt Abhängigkeiten zwischen den Modulen; diese Abhängigkeiten werden von modprobe(8) genutzt.

[Anmerkung] Anmerkung

Wenn Sie Probleme beim Laden von Modulen feststellen, entweder während des Systemstarts oder beim Nachladen mit modprobe(8), kann "depmod -a" diese Probleme möglicherweise durch Neuerstellung der "modules.dep"-Datei beheben.

Der Befehl modinfo(8) zeigt Informationen über ein Linux-Kernel-Modul an.

Das lsmod(8)-Programm formatiert den Inhalt von "/proc/modules" zu einer hübschen Ausgabe, um anzuzeigen, welche Kernel-Module gerade geladen sind.

[Tipp] Tipp

Sie können die Hardware in Ihrem System exakt identifizieren. Lesen Sie dazu Abschnitt 9.4.3, „Hardware-Identifikation“.

[Tipp] Tipp

Möglicherweise wollen Sie Hardware während des Systemstarts konfigurieren, um bestimmte erwartete Hardware-Funktionalitäten zu aktivieren. Näheres finden Sie in Abschnitt 9.4.4, „Hardware-Konfiguration“.

[Tipp] Tipp

Unterstützung für spezielle Geräte können Sie unter Umständen durch Neukompilieren des Kernels hinzufügen. Details finden Sie in Abschnitt 9.9, „Der Kernel“.