bootup - Systemstartprozess
Beim Systemstart eines Linux-Systems sind eine Reihe von verschiedenen
Komponenten beteiligt. Direkt nach dem Einschalten führt die
Systemfirmware eine minimale Hardware-Initialisierung durch. Dann wird die
Steuerung an einen auf dem dauerhaften Speichergerät gespeicherten
Bootloader (z.B.
systemd-boot(7) oder
GRUB[1]) abgegeben. Dieser
Bootloader wird dann einen Betriebssystemkernel von der Platte (oder dem
Netzwerk) aufrufen. Auf Systemen, die EFI oder andere Arten von Firmware
verwenden, kann diese Firmware auch den Kernel direkt laden.
Der Kernel hängt (optional) ein speicherinternes Dateisystem ein, das oft
mittels
dracut(8) erstellt wurde und ein Wurzeldateisystem sucht.
Heutzutage ist die Implementierung ein »initramfs« – ein
komprimiertes Archiv, das der Kernel in ein Tmpfs extrahiert. In der
Vergangenheit wurden dafür normale Dateisysteme unter Verwendung eines
speicherinternen Blockgerätes (Ramdisk) verwandt und der Name
»Initrd« wird weiterhin für die Beschreibung beider
Konzepte verwandt. Der Bootloader oder die Firmware lädt sowohl den
Kernel als auch die Initrd/das Initramfs in den Speicher, aber der Kernel
interpretiert es als Dateisystem.
systemd(1) kann zur Verwaltung von
Diensten in der Initrd, ähnlich wie bei einem realen System, verwandt
werden.
Nachdem das Wurzeldateisystem gefunden wurde und eingehängt worden ist,
übergibt die Initrd die Steuerung an den Systemverwalter (wie
systemd(1)) des eigentlichen Systems. Dieser ist im Wurzeldateisystem
gespeichert und ist für die Erkennung der verbleibenden Hardware, dem
Einhängen aller notwendigen Dateisysteme und dem Starten aller
konfigurierten Dienste verantwortlich.
Beim Herunterfahren beendet der Systemverwalter alle Dienste, hängt alle
Dateisysteme aus (trennt alle hinterlegten Speichertechniken ab) und springt
dann (optional) zurück in den Initrd-Code, der das Wurzeldateisystem
und den Speicher, auf dem es liegt, aushängt und abtrennt. Als letzten
Schritt wird das System ausgeschaltet.
Zusätzliche Informatioen über den Systemstartprozess können
in
boot(7) gefunden werden.
Beim Systemstart ist der Systemverwalter im Betriebssystem-Image für die
Initialisierung der benötigten Dateisysteme, Dienste und Treiber
verantwortlich, die für den Betrieb des Systems notwendig sind. Auf
systemd(1)-Systemen ist dieser Vorgang in verschiedene diskrete
Schritte aufgeteilt, die als Ziel-Units offengelegt sind. (Siehe
systemd.target(5) für detaillierte Informationen über
Ziel-Units.) Der Systemstartvorgang ist in hohem Maße parallelisiert,
so dass die Reihenfolge, in der bestimmte Ziel-Units erreicht werden, nicht
deterministisch ist, aber dennoch in einem begrenzten Umfang einer
Ordnungsstruktur folgt.
Wenn Systemd das System hochfährt, wird es standardmäßig
alle Units aktivieren, die Abhängigkeiten von default.target sind
(sowie rekursiv alle Abhängigkeiten dieser Abhängigkeiten).
Normalerweise ist default.target einfach ein Alias von graphical.target oder
multi-user.target, abhängig davon, ob das Ssytem für eine
graphische Benutzerschnittstelle oder nur für eine Textkonsole
konfiguriert ist. Um eine minimale Ordnung zwischen den hereingezogenen Units
zu erzwingen, sind eine Reihe von gut bekannten Ziel-Units verfügbar,
wie in
systemd.special(7) aufgeführt.
Das nachfolgende Diagramm gibt einen strukturellen Überblick über
diese gut bekannten Units und ihre Position in der Systemstartlogik. Die
Pfeile beschreiben, welche Units hereingezogen und vor welchen anderen Units
sortiert werden. Units im oberen Bereich werden vor Units im unteren Bereich
des Diagramms gestartet.
cryptsetup-pre.target veritysetup-pre.target
|
(verschiedene systemnahe v
API-VFS-Einhängungen: (verschiedene Cryptsetup/Veritysetup-Geräte…)
mqueue, configfs, | |
debugfs, …) v |
| cryptsetup.target |
| (verschiedene Auslagerungs- | | remote-fs-pre.target
| Geräte…) | | | |
| | | | | v
| v local-fs-pre.target | | | (Netzwerkdateisysteme)
| swap.target | | v v |
| | v | remote-cryptsetup.target |
| | (verschiedene systemnahe (verschiedene | remote-veritysetup.target |
| | Dienste: udevd, Einhänge- und | | remote-fs.target
| | tmpfiles, random Fsck-Dienste…) | | |
| | seed, sysctl, …) v | | _____________/
| | | local-fs.target | |
| | | | | |
\____|______|_______________ ______|___________/ |
\ / |
v |
sysinit.target |
| |
______________________/|\_____________________ |
/ | | | \ |
| | | | | |
v v | v | |
(verschiedene (verschiedene | (verschiedene | |
Timer…) Pfade…) | 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- (verschiedene (verschiedene |
manager.service Systemdienste Systemdienste) |
| benötigt für | |
| graphische UIs) v v
| | multi-user.target
emergency.service | | |
| \_____________ | _____________/
v \|/
emergency.target v
graphical.target
Ziel-Units, die typischerweise als Systemstart-Ziele verwandt werden, sind
hervorgehoben. Diese Units sind eine gute Wahl für Ziele,
beispielsweise, indem sie an die Befehlszeilenoption
systemd.unit= des
Kernels übergeben werden (siehe
systemd(1)) oder indem
default.target auf sie verlinkt wird.
timers.target wird asynchron von basic.target hereingezogen. Dies
ermöglicht es Timer-Units, von Diensten, die erst später beim
Systemstart verfügbar werden, abzuhängen.
Der Systemverwalter startet für jeden Benutzer die Unit Benutzer@
UID.service, die jeweils eine separate, unprivilegierte Instanz von
systemd für jeden Benutzer startet — den
Benutzerverwalter. Ähnlich zum Systemverwalter startet der
Benutzerverwalter Units, die von default.target hereingezogen werden. Das
folgende Diagramm ist ein strukturelle Überblick über die
gutbekannten Benutzer-Units. Für nichtgraphische Sitzungen wird
default.target verwandt. Wannimmer sich ein Benutzer in einer graphischen
Sitzung anmeldet, wird der Anmeldeverwalter das Ziel graphical-session.target
starten, das die für die graphische Sitzung benötigten Units
hereinzieht. Eine Reihe von Zielen (auf der rechten Seite gezeigt) werden
gestartet, wenn eine bestimmte Hardware dem Benutzer zur Verfügung
steht.
(verschiedene (verschiedene (verschiedene
Timer…) Pfade…) Sockets…) (Sound-Geräte)
| | | |
v v v v
timers.target paths.target sockets.target sound.target
| | |
\______________ _|_________________/ (Bluetooth-Geräte)
\ / |
V v
basic.target bluetooth.target
|
__________/ \_______ (Smartcard-Geräte)
/ \ |
| | v
| v smartcard.target
v graphical-session-pre.target
(verschiedene Benutzerdienste) | (Drucker)
| v |
| (Dienste für die graphische Sitzung) v
| | printer.target
v v
default.target graphical-session.target
Systemd kann auch in der Initrd verwandt werden. Es erkennt die Initrd durch
Prüfung auf die Datei /etc/initrd-release. Das Vorgabe-Ziel in der
Initrd ist initrd.target. Der Systemstartprozess ist bis zum Ziel basic.target
identisch zum Systemverwalterstart. Danach führt Systemd das besondere
Ziel initrd.target aus. Bevor irgendwelche Dateisysteme eingehängt
werden, muss der Verwalter bestimmen, ob das System aus dem Ruhezustand
zurückkehren oder ob mit dem normalen Systemstart fortgefahren werden
soll. Dies wird durch
[email protected] erreicht, der vor dem
local-fs-pre.target fertig werden muss, so das keine Dateisystem
eingehängt werden können, bevor die Prüfung abgeschlossen
ist. Wenn das Wurzeldateisystem verfügbar wird, ist
initrd-root-device.target erreicht. Falls das Wurzelverzeichnis als /sysroot
eingehängt werden kann, wird die Unit sysroot.mount aktiv und
initrd-root-fs.target ist erreicht. Der Dienst initrd-parse-etc.service
durchsucht /sysroot/etc/fstab nach einem möglichen Einhängepunkt
für /usr/ und zusätzlichen Einträgen, die mit der Option
x-initrd.mount markiert sind. Alle gefundenen Einträge werden
unter /sysroot eingehängt und initrd-fs.target ist erreicht. Der Dienst
initrd-cleanup.service isoliert zu dem initrd-switch-root.target, in dem
Aufräumdienste laufen können. Als allerletzten Schritt wird
initrd-switch-root.service aktiviert, das dazu führt, dass das System
seine Wurzel auf /sysroot umschaltet.
: (Anfang identisch zu oben)
:
v
basic.target
| emergency.service
______________________/| |
/ | v
| initrd-root-device.target emergency.target
| |
| v
| sysroot.mount
| |
| v
| initrd-root-fs.target
| |
| v
v initrd-parse-etc.service
(custom initrd |
services...) v
| (sysroot-usr.mount und
| verschiedene Einhängungen markiert
| mit Fstab-Option
| x-initrd.mount…)
| |
| v
| initrd-fs.target
\______________________ |
\|
v
initrd.target
|
v
initrd-cleanup.service
isoliert zu
initrd-switch-root.target
|
v
______________________/|
/ v
| initrd-udevadm-cleanup-db.service
v |
(angepasste Initrd- |
Dienste…) |
\______________________ |
\|
v
initrd-switch-root.target
|
v
initrd-switch-root.service
|
v
Übergang ins Hauptbetriebssystem
Der Abschaltvorgang mit Systemd besteht auch aus verschiedenen Ziel-Units mit
einiger minimaler Ordnungsstruktur:
(Konflikt zu (Konflikt zu allen
allen System- Dateisystemeinhängungen,
diensten) Auslagerungen,
| Cryptsetup-/
| Veritysetup-
| Geräten, …)
| |
v v
shutdown.target umount.target
| |
\___________ __________/
\ /
v
(verschiedene systemnahe
Dienste)
|
v
final.target
|
___________________________/ \_________________
/ | | \
| | | |
v | | |
systemd-reboot.service | | |
| v | |
| systemd-poweroff.service | |
v | v |
reboot.target | systemd-halt.service |
v | v
poweroff.target | systemd-kexec.service
v |
halt.target |
v
kexec.target
Häufig verwandte Ziele beim Herunterfahren des Systems sind
hervorgehoben.
Beachten Sie, dass
systemd-halt.service(8), systemd-reboot.service,
systemd-poweroff.service und systemd-kexec.service das System und den
Diensteverwalter (PID 1) in die zweite Phase des Systemherunterfahrens
überleiten (was im Programm systemd-shutdown implementiert ist). Dieser
wird in einer einfachen und robusten Weise alle verbleibenden Dateisysteme
aushängen, alle verbleibenden Prozesse töten und alle
verbleibenden Ressourcen freigeben, ohne das Dienste- oder Unit-Konzept noch
in Betracht zu ziehen. Zu diesem Zeitpunkt sind gewöhnliche Anwendungen
und Ressourcen im Allgemeinen bereits beendet und freigegeben, die zweite
Phase agiert daher nur als Sicherheitsnetz für alles, das aus
irgendeinem Grund nicht während des oben beschriebenen,
primären, Unit-basierten Herunterfahrens beendet oder freigegeben
werden konnte.
systemd(1),
boot(7),
systemd.special(7),
systemd.target(5),
systemd-halt.service(8),
dracut(8)
- 1.
- GRUB
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<
[email protected]> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
Sie bitte eine E-Mail an die
Mailingliste
der Übersetzer