|
|
| (89 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| | '''systemd''' - [[Init-System]] und Systemmanager |
|
| |
|
| = systemd =
| | {| class="wikitable options" |
| {| class="wikitable sortable" | |
| |-
| |
| || [https://de.wikipedia.org/wiki/Maintainer Maintainer]
| |
| || [https://de.wikipedia.org/wiki/Lennart_Poettering Lennart Poettering], [https://de.wikipedia.org/wiki/Kay_Sievers Kay Sievers] ([https://de.wikipedia.org/wiki/Red_Hat Red Hat] Inc.)
| |
| |-
| |
| || '''Erscheinungsjahr'''
| |
| || 30. März 2010
| |
| |-
| |
| || '''Aktuelle [https://de.wikipedia.org/wiki/Version_%28Software%29 Version]
| |
| || 224 (31. Juli 2015)
| |
| |-
| |
| || [https://de.wikipedia.org/wiki/Betriebssystem Betriebssystem]
| |
| || [https://de.wikipedia.org/wiki/Linux Linux]
| |
| |-
| |
| || [https://de.wikipedia.org/wiki/Programmiersprache Programmiersprache]
| |
| || [https://de.wikipedia.org/wiki/C_%28Programmiersprache%29 C]
| |
| |-
| |
| || '''Kategorie'''
| |
| || [https://de.wikipedia.org/wiki/Init init]-Dienst
| |
| |-
| |
| || '''Lizenz'''
| |
| || [https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License GNU LGPL] 2.1+ ([https://de.wikipedia.org/wiki/Freie_Software Freie Software])
| |
| |-
| |
| | colspan="2" align=center| [http://freedesktop.org/wiki/Software/systemd freedesktop.org/wiki/Software/systemd]
| |
| |- | | |- |
| | | Beschreibung || [[Systemd/Beschreibung]] |
| | |- |
| | | Installation || [[Systemd/Installation]] |
| | |- |
| | | Syntax || [[Systemd/Syntax]] |
| | |- |
| | | Anwendung || [[Systemd/Anwendung]] |
| | |- |
| | | Konfiguration || [[Systemd/Konfiguration]] |
| |} | | |} |
|
| |
|
| * '''systemd''' ist ein Hintergrundprogramm ([https://de.wikipedia.org/wiki/Daemon Daemon]) für [https://de.wikipedia.org/wiki/Linux Linux]-Systeme, das als [https://de.wikipedia.org/wiki/Init init]-Prozess als erster [https://de.wikipedia.org/wiki/Prozess_%28Informatik%29 Prozess] ([https://de.wikipedia.org/wiki/Process_identifier Prozess-ID] 1) zum Starten, Überwachen und Beenden weiterer Prozesse dient.
| | <noinclude> |
| * Es wurde von [https://de.wikipedia.org/wiki/Lennart_Poettering Lennart Poettering], [https://de.wikipedia.org/wiki/Kay_Sievers Kay Sievers] ([https://de.wikipedia.org/wiki/Red_Hat Red Hat] Inc.) und Anderen in [https://de.wikipedia.org/wiki/C_%28Programmiersprache%29 C] geschrieben und wird als [https://de.wikipedia.org/wiki/Freie_Software freie Software] unter der [https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License GNU Lesser General Public License] (LGPL) veröffentlicht.
| | == Anhang == |
| * Der Name entspricht mit dem abschließenden „d“ dem für Daemons üblichen Namensschema: systemd ist der Daemon, der das System startet und betreut.
| | === Siehe auch === |
| | | {{Special:PrefixIndex/{{BASEPAGENAME}}}} |
| == Geschichte ==
| | ==== Dokumentation ==== |
| == Ideen und Konzepte == | |
| * Die Ideen und Konzepte zu systemd entstanden aus der Betrachtung von bereits bestehenden modernisierten init-Systemen wie [https://de.wikipedia.org/wiki/Launchd launchd] von [https://de.wikipedia.org/wiki/Mac_OS_X Mac OS X] und SMF ([https://de.wikipedia.org/wiki/Service_Management_Facility Service Management Facility]) von [https://de.wikipedia.org/wiki/Solaris_%28Betriebssystem%29 Solaris]. Es wurde am 10. April 2010 veröffentlicht.
| |
| | |
| == Distributionen == | |
| Distributionen, die systemd als vorgegebenen init-Dienst verwenden, sind [https://de.wikipedia.org/wiki/Fedora_%28Linux-Distribution%29 Fedora] seit Version 15, [https://de.wikipedia.org/wiki/OpenSUSE openSUSE] seit Version 12.1, [https://de.wikipedia.org/wiki/Mandriva_Linux Mandriva] 2011, [https://de.wikipedia.org/wiki/Mageia Mageia] seit Version 2, [https://de.wikipedia.org/wiki/Arch_Linux Arch Linux] seit Oktober 2012, [https://de.wikipedia.org/wiki/Red_Hat_Enterprise_Linux Red Hat Enterprise Linux] seit Version 7, [https://de.wikipedia.org/wiki/Tizen Tizen] sowie [https://de.wikipedia.org/wiki/Siduction siduction] seit Version 2013.2, [https://de.wikipedia.org/wiki/SUSE_Linux_Enterprise_Server SUSE Linux Enterprise Server] seit Version 12, [https://de.wikipedia.org/wiki/Ubuntu Ubuntu] seit Version 15.04 und [https://de.wikipedia.org/wiki/Debian Debian] ab Version 8.
| |
| | |
| == [https://de.wikipedia.org/wiki/D-Bus D-Bus] ==
| |
| Ab Version 221 beinhaltet systemd ''sd-bus'', eine unabhängige [https://de.wikipedia.org/wiki/D-Bus D-Bus]-[https://de.wikipedia.org/wiki/Programmierschnittstelle Programmierschnittstelle], die bei der Komplexität zwischen [https://de.wikipedia.org/w/index.php?title=Libdbus&action=edit&redlink=1 libdbus] und [https://de.wikipedia.org/w/index.php?title=GDBus&action=edit&redlink=1 GDBus] angesiedelt ist. sd-bus unterstützt sowohl das klassische dbus1 im [https://de.wikipedia.org/wiki/Userspace Userspace] als auch [https://de.wikipedia.org/wiki/Kdbus kdbus] als Backend und soll so den reibungslosen Übergang zur Interprozesskommunikation im Kernel ermöglichen.
| |
| | |
| == Technik == | |
| * systemd ist abwärtskompatibel zu [https://de.wikipedia.org/wiki/SysVinit SysVinit]-Skripten. Allerdings werden bewusst Features benutzt, die nur unter Linux zur Verfügung stehen, nicht aber auf anderen [https://de.wikipedia.org/wiki/Unixoides_System unixoiden Betriebssystemen]. Es kann daher nur auf Systemen mit Linux-Kernel laufen.
| |
| * [[Image:.png|thumb|right|Abbildung 1: systemd-Komponenten]]Es soll den gegenseitigen Abhängigkeiten von Prozessen besser gerecht werden, durch mehr Parallelisierung zu einer besseren Auslastung beim Systemstart führen und somit weniger Verzögerungen verursachen als das ältere, klassische SysVinit oder das inzwischen auch von Ubuntu aufgegebene [https://de.wikipedia.org/wiki/Upstart Upstart].
| |
| * Grundlegendes Konzept dafür ist es, weitgehend alle Prozesse gleichzeitig zu starten.
| |
| * Um nicht, wie bei anderen zwar grundsätzlich auf Parallelisierung setzenden Systemen, anhand der in einem Modell erfassten wechselseitigen Abhängigkeiten der Prozesse teilweise noch mit Serialisierung zu arbeiten, werden die [https://de.wikipedia.org/wiki/D-Bus D-Bus]-Verbindungen und [https://de.wikipedia.org/wiki/Socket_%28Software%29 Sockets] zur [https://de.wikipedia.org/wiki/Interprozesskommunikation Interprozesskommunikation] schon vor dem Start des zugehörigen Dienstes bereitgestellt und vom [https://de.wikipedia.org/wiki/Kernel_%28Betriebssystem%29 Kernel] eventuell auflaufende Nachrichten bis zur Bereitschaft des Dienstes [https://de.wikipedia.org/wiki/Puffer_%28Informatik%29 gepuffert].
| |
| * Ähnliches wird für Anfragen an Dateisysteme mittels [https://de.wikipedia.org/w/index.php?title=Autofs&action=edit&redlink=1 autofs] bewerkstelligt.
| |
| * Daneben kann es nur gelegentlich benötigte Dienste ereignisbasiert erst bei Bedarf starten und so beim Systemstart weniger Dienste starten. Damit nimmt es Aufgaben wahr, die bei klassischen Unix-Systemen von [https://de.wikipedia.org/wiki/Inetd inetd] übernommen werden.
| |
| * Weiterhin sollen alle Shell-Boot-Skripte durch deklarative Konfigurationsdateien ersetzt werden, in denen definiert wird, wie die jeweiligen Dienste gestartet werden. Diese Dateien sind in der Regel deutlich einfacher zu schreiben als init-Skripte und vermeiden den erheblichen Overhead von Shell-Skripten.
| |
| | |
| == Kritik == | |
| * Der Hauptkritikpunkt am systemd liegt in seinem Anspruch, deutlich mehr verschiedene Aufgaben als das alte SysV-Init erledigen zu wollen, was ihn recht kompliziert und fehleranfällig mache und überdies die [https://de.wikipedia.org/wiki/Unix-Philosophie Unix-Philosophie] verletze, dass ein Programm ein Problem gut lösen sollte, anstatt viele Aufgaben schlecht zu lösen.
| |
| | |
| = Aufgaben = | |
| * Der Init-Prozess ist der erste Prozess, den der Kernel erzeugt. Alle weiteren Prozesse sind Kinder des Init-Prozesses, der daher die Verantwortung für die komplette Einrichtung des Userlands trägt.
| |
| * Dazu gehört nicht nur das Einhängen von Dateisystemen und die Netzwerkeinrichtung, sondern auch das Starten von Hintergrund-Diensten und Programmen – darunter auch jene, über die sich Benutzer am System anmelden.
| |
| * Nach dem Abschluss der Systemeinrichtung läuft der Init-Prozess weitgehend untätig im Hintergrund weiter. Er kommuniziert mit dem Kernel und wird beispielsweise informiert, wenn der Benutzer Strg+Alt+Entf drückt.
| |
| * Genau wie beim Aufruf von Befehlen wie <tt>shutdown -r now </tt>oder <tt>reboot</tt> erledigt der Prozess mit der PID 1 dann alles Nötige, um das System sauber zum Stillstand zu bringen.
| |
| * Mit diesen Aufgaben wurde in den 80er Jahren in Unix System V das einfache, aber flexible "System V Init System" betraut. In den 90er Jahren entstand eine Sysvinit genannte Neuimplementierung dieses Init-Systems.
| |
| * Sie arbeitet mit einer ganz ähnlichen Logik und kommt bis heute bei vielen Linux-Distributionen zum Einsatz. Sysvinit erledigt die Aufgaben des Systemstarts im Wesentlichen mit Shell-Skripten, die einfach der Reihe nach abgearbeitet werden.
| |
| * Mit der Verbreitung von Linux in Mobilgeräten, Desktop-PCs, Fernsehern und zahlreichen anderen Gebieten wandelten sich allerdings die Anforderungen an den Init-Prozess: Der Systemstart sollte flexibler werden und dank Parallelisierung deutlich schneller ablaufen.
| |
| | |
| = Herangehensweisen =
| |
| * Lange schien es, als wäre '''das 2006 '''von einem Canonical-Entwickler gestartete Upstart der designierte Nachfolger für Sysvinit (siehe den Artikel '''Schneller booten mit Upstart '''auf heise open).
| |
| * Anfangs kam es nur bei Ubuntu zum Einsatz, später auch bei Fedora (Versionen 9 bis 14) und Red Hat Enterprise Linux (RHEL6-Familie). OpenSuse experimentierte während der Arbeit an der Version 11.3 mit Upstart, blieb letztlich jedoch bei Sysvinit.
| |
| * Upstart ist ein ereignisorientiertes Init-System – es kann Dienste starten, wenn Ereignisse wie "Netzwerk ist konfiguriert" oder "Netzlaufwerk ist eingebunden" eintreten.
| |
| * Der Ansatz unterscheidet sich stark von dem statischen Sysvinit, daher lassen sich bestehende Konfigurationen nur schwer oder gar nicht in das Ereignis-Modell von Upstart übertragen.
| |
| * Im '''April 2010 '''erschien Systemd; es bedient sich einiger Ideen aus früheren Unit-Systemen und kombiniert diese mit einer einheitlichen Konfigurations- und Administrationsschnittstelle. Systemd arbeitet als Hintergrunddienst (Daemon) und steuert wichtige Aspekte der Systemkonfiguration von der Initialisierung der Hardware bis zu den gestarteten Server-Prozessen.
| |
| * Der Name erschien den Entwicklern als eine '''passende Verbindung '''zum französischen Begriff "Système D" (etwa: "Trick 17"), der kreative technische Lösungsansätze à la '''MacGyver '''beschreibt.
| |
| | |
| = Hintenrum =
| |
| * Zentrales Merkmal von Systemd ist die Socket-Aktivierung, durch die der Daemon Hintergrunddienste ohne explizite Konfiguration der Abhängigkeiten parallel starten kann, sobald die Grundeinrichtung des Systems abgeschlossen und die lokalen Dateisysteme eingebunden sind.
| |
| * Der Trick besteht darin, dass Systemd die Sockets zur Kommunikation mit den zu startenden Diensten selbst anlegt und dorthin geschriebene Daten zwischenspeichert, bis sie der gestartete Dienst entgegennehmen kann.
| |
| * Illustrieren lässt sich das Konzept am Beispiel der Dienste Syslog und D-Bus. Letzterer verbindet sich beim Start mit dem Socket /dev/log, um darüber bei Bedarf Status- und Fehlermeldungen über den Log-Daemon ins Systemlog zu schreiben. Sysvinit kann daher D-Bus erst starten, wenn der Syslog-Dienst voll einsatzbereit ist.
| |
| * Systemd hingegen legt /dev/log selbst an und startet Syslog und D-Bus gleichzeitig; dabei werden die Daten, die D-Bus an /dev/log schickt, gepuffert, bis sie Syslog entgegennimmt. Anfangs überließ Systemd dem Kernel das Puffern; bei aktuellen Versionen vom Systemd kümmert sich die '''dort enthaltene '''Log-Funktion "Journal" um diese Aufgabe.
| |
| * Systemd kann so auch Bluetooth, Avahi und weitere Dienste, die mit dem Log-Daemon oder D-Bus kommunizieren, parallel mit Syslog und D-Bus starten.
| |
| * Wenn Avahi beim Start eine Antwort von D-Bus erwartet, stoppt der Prozess an dieser Stelle automatisch und setzt den Start ohne weiteres Zutun fort, sobald die Antwort über den Socket eintrifft. Sollte D-Bus aus irgendeinem Grund nicht anlaufen, bricht Systemd den Start von Bluetooth und Avahi nach einiger Zeit ab.
| |
| * Apple verwendet dasselbe Prinzip in seinem mit Mac OS X 10.4 eingeführten '''Launchd ''', der auch bei iOS zum Einsatz kommt und als Hauptgrund für den deutlich verkürzten Startprozess neuerer Mac-OS-Versionen gilt, da der Parallelstart der Dienste die verfügbaren CPU- und I/O-Ressourcen effizienter nutzt.
| |
| * Bei Sysvinit starten die Dienste hingegen in einer festgelegten Reihenfolge – Bluetooth und Avahi erst, wenn der D-Bus-Daemon läuft, der wieder erst startet, wenn das Syslog bereit ist. Selbst Bluetooth und Avahi, die voneinander unabhängig sind, starten nicht bei allen Sysvinit-Distributionen parallel.
| |
| | |
| = Bedarfsanforderung =
| |
| * Da Systemd den Socket erstellt und hält, kann der Daemon einen abgestürzten Dienst neu starten, ohne dass mit dem Socket verbundene Programme die Verbindung verlieren.
| |
| * Dadurch lassen sich System-Komponenten einfacher aktualisieren, da der Kernel die über den Socket eingehenden Client-Anfragen während des Neustarts puffert und der neue Dienst einfach dort fortfahren kann, wo der alte aufgehört hat.
| |
| * Sockets lassen sich zudem an verschiedene Programme übergeben. Systemd nutzt das zum Loggen von früher Statusmeldungen:
| |
| * Solange das Root-Dateisystem noch nicht beschreibbar eingebunden ist, nimmt ein minimaler Log-Dienst Daten entgegen, die nach /dev/log geschrieben werden, und schreibt sie in den Kernel-Log-Puffer. Sobald der eigentliche Syslog-Server bereits ist, wird der Minidienst beendet; der Syslog-Daemon übernimmt den Socket und schreibt dabei alle zuvor aufgelaufenen Nachrichten aus dem Kernel-Log-Buffer auf die Festplatte.
| |
| * So gehen keine Nachrichten verloren, was eine Protokollierung vom ersten Moment des Bootens an ermöglicht.
| |
| | |
| = Einheiten =
| |
| * Die verschiedenen Tätigkeiten beim Systemstart – Sockets anlegen, Hardware einrichten, Datenträger einbinden, Hintergrunddienste starten und so weiter – sind in sogenannten Units organisiert.
| |
| * Für jede Aufgabe, die Systemd ausführen soll, benötigt man eine Unit-spezifische Konfigurationsdatei – bei einer Mount-Unit beispielsweise muss die Konfiguration lediglich die Device-Datei des Datenträgers und das Zielverzeichnis enthalten.
| |
| * Diese Unit-Dateien sind erheblich kürzer als traditionelle Init-Skripte. Syntaktisch ähneln sie den Ini-Dateien von Windows.
| |
| | |
| Den Typ einer Unit erkennt Systemd am Dateinamen. Dateien, die auf <tt>.service</tt> enden, legen Service-Units an; sie kümmern sich um Hintergrunddienste.
| |
| | |
| Units zum Ein- und Aushängen von Dateisystemen enden auf <tt>.mount</tt>; das Suffix lautet <tt>.automount</tt>, wenn dabei der Automounter involviert ist, der Dateisysteme beim Zugriff automatisch einhängt. Units mit dem Suffix <tt>.path</tt> weisen Systemd an, die spezifizierten Dateien und Verzeichnisse via Inotify überwachen; erfolgt dort ein Zugriff, startet Systemd diese Unit.
| |
| | |
| Auf <tt>.socket</tt> endende Unit-Dateien legen einen oder mehrere Sockets für die Socket-Aktivierung an. Der zugehörige Dienst wird erst dann über eine zu der Socket-Unit gehörende Service-Unit gestartet, wenn ein anderer Prozess Daten auf den Socket schreibt.
| |
| | |
| Der geöffnete Socket wird dabei an den Dienst übergeben – ähnlich wie es alte Unix-/Linux-Hasen von Inetd kennen.
| |
| | |
| Die Unit-Dateien von Systemd und den Systemdiensten liegen im Verzeichnis /lib/systemd/system/; liegt eine gleichnamige Datei in /etc/systemd/system/, ignoriert Systemd die im Lib-Verzeichnis.
| |
| | |
| Der Administrator kann so eine Unit-Datei von Systemd kopieren und an seine Belange anpassen, ohne fürchten zu müssen, dass sie beim nächsten Update überschrieben wird – das konnte bei Sysvinit-Distributionen passieren, wenn man eines der in /etc/rc.d/init.d/ gespeicherten Init-Skripte von Hand veränderte.
| |
| | |
| Systemd erzeugt einige Units dynamisch selbst; sie tauchen daher nicht im Dateisystem, sondern nur in der mit <tt>systemctl</tt> abrufbaren Liste der Units auf.
| |
| | |
| So wird für einige Geräte wie Datenträger, PCI-Geräte und TTYs im Zusammenspiel mit Udev automatisch eine Device-Unit generiert, wenn sie in den Udev-Regeln mit <tt>TAG+="systemd"</tt> gekennzeichnet sind.
| |
| | |
| Ähnlich wie beim Zweigespann aus Socket- und Service-Unit können andere Units von diesen Device-Units abhängen und so automatisch starten, wenn Geräte auftauchen, auf die sie angewiesen sind.
| |
| | |
| Dieses System kommt auch bei den .swap-Units zum Einsatz, die automatisch mit Hilfe der Angaben in /etc/fstab angelegt werden und die den Auslagerungsspeicher einbinden, sobald das spezifizierte Swap-Volume auftaucht.
| |
| | |
| Systemd erzeugt auch für einige andere in /etc/fstab spezifizierte Datenträger automatisch Mount-Units, daher tauchen in der Systemctl-Liste mehr Mount-Units auf, als man Konfigurationsdateien findet.
| |
| | |
| = Ziele =
| |
| | |
| Unit-Dateien, die auf <tt>.target</tt> enden, definieren Gruppen aus Units. Sie leisten selbst wenig, rufen vielmehr andere Units auf, die für Dienste, Dateisysteme und andere Dinge zuständig sind.
| |
| | |
| So lassen sich Boot-Ziele definieren, die den klassischen Sys-V-Runlevels entsprechen. Die Unit <tt>multi-user.target</tt> etwa sorgt für den Start all jener Dienste, die ältere Fedora- und OpenSuse-Versionen im Runlevel 3 aufrufen würden – voller Multiuser-Netzwerkbetrieb ohne grafischen Anmeldemanager.
| |
| | |
| Letzterer erscheint bei der Unit <tt>graphical.target</tt>, die damit das Äquivalent zum Runlevel 5 darstellt und typischerweise das Standard-Ziel ist.
| |
| | |
| Beim Hochfahren des Systems aktiviert Systemd die spezielle Target-Unit <tt>default.target</tt>, typischerweise ein Alias eines anderen Targets wie <tt>graphical.target</tt> oder <tt>multi-user.target</tt>.
| |
| | |
| Die Targets können zudem aufeinander aufbauen oder voneinander abhängen; <tt>graphical.target </tt>etwa wartet den Start von <tt>multi-user.target</tt> ab, bevor es die grafische Oberfläche startet.
| |
| | |
| Wo nötig lassen sich über die Angabe von "Wants" in den Unit-Dateien manuell Abhängigkeiten zwischen den Units definieren – wichtig beispielsweise für Dienste wie den Apache-Webserver, der beim Start eine voll konfigurierte Netzwerkumgebung erwartet.
| |
| | |
| Solche Dienste sollten von <tt>network.target</tt> abhängen. Bei Diensten wie Avahi oder Bind ist eine solche Abhängigkeit nicht nötig, da diese auch mit Netzwerk-Interfaces zurechtkommen, die zur Laufzeit erscheinen oder verschwinden.
| |
| | |
| = Althergebrachtes =
| |
| | |
| Aus Kompatibilitätsgründen versteht sich Systemd auch mit System-V- und LSB-Init-Skripten, die nicht nur von Sysvinit-Distributionen verwendet werden, sondern auch mit Upstart funktionieren.
| |
| | |
| Diese Init-Skripte werden durch eine Shell interpretiert und erfordern einen Parameter wie "start", "stop" oder "restart".
| |
| | |
| Auch die Hersteller kommerzieller Software legen ihren Hintergrunddiensten typischerweise Sys-V- und LSB-Init-Skripte bei. Um sie intern wie eine richtige Service-Unit zu behandeln, generiert Systemd daraus automatisch eine Service-Unit; das Init-Tool ignoriert allerdings Sys-V- und LSB-Init-Skripte, wenn es eine Unit-Datei mit gleichem Namen findet.
| |
| | |
| = Gruppen =
| |
| | |
| Systemd packt jeden Dienst beim Start in eine eigene, nach dem Dienst benannte '''Control Group'''. Diese Technik isoliert die Prozesse und bietet mit Hilfe '''optionaler Controller '''Stellschrauben, um die Verteilung der Ressourcen zu beeinflussen. Kindprozesse erben die Gruppenzugehörigkeit.
| |
| | |
| Systemd kann so Prozessgruppen als zusammengehörige Einheiten verwalten, um etwa beim Beenden eines Dienstes alle zugehörigen Prozesse zuverlässig zu stoppen. Administratoren können über die normalen Cgroup-Schnittstellen den Ressourcenverbrauch von Diensten kontrollieren; die manuelle Zuordnung der Prozesse entfällt.
| |
| | |
| = Breiterer Ansatz =
| |
| | |
| Systemd liegen eine Reihe von Units bei, die einige grundsätzliche Dinge bei der Initialisierung des Systems erledigen. Teilweise sind diese wie ein Hintergrunddienst angelegt.
| |
| | |
| Die Service-Unit <tt>fsck-root.service</tt> etwa veranlasst bei Bedarf eine Prüfung des Root-Dateisystems, bevor es durch <tt>remount-rootfs.service</tt> beschreibbar eingebunden wird.
| |
| | |
| Die Service-Units <tt>hwclock-load</tt> und <tt>hwclock-save</tt> sorgen für einen Abgleich der Zeit mit der Systemuhr.
| |
| | |
| Bei Sysvinit- und Upstart-Distributionen kümmern sich Shell-Skripte um derartige Aufgaben, etwa /etc/rc.sysinit oder eine Sammlung kleiner Skripte in /etc/rcS.d/.
| |
| | |
| Diese Skripte sind stark auf die jeweilige Distributionsfamilie zugeschnitten und verhalten sich daher bei Debian ganz anders als bei Fedora oder OpenSuse; das ist der Grund, warum man bei Fedora und RHEL in /etc/sysconfig/keyboard die Tastatur festlegen kann, dieses Verzeichnis bei Debian aber vergeblich sucht.
| |
| | |
| Viele Systemd-Units starten C-Programme, die schneller und robuster sein sollen als die Shell-Skipte, die diese Aufgaben bisher erledigten.
| |
| | |
| Mit der Integration dieser Dienste versucht Systemd viele Unterschiede zwischen den Distributionen aus der Welt zu schaffen.
| |
| | |
| Das erleichtert Entwicklern die Arbeit, denn sie können Unit-Dateien für ihre Dienste mitliefern und dabei die Dinge erwarten, die Systemd beiliegen.
| |
| | |
| Sys-V-Init-Skripte beizulegen ist erheblich schwieriger, weil diese auf distributionsspezifische Eigenarten Rücksicht nehmen müssen.
| |
| | |
| = Details =
| |
| | |
| Weitere Hintergründe zu Ideen, Arbeitsweisen und Einsatz von Systemd liefern die '''Man-Pages zu Systemd '''– etwa '''systemd '''und '''systemd.conf '''.
| |
| | |
| Auch für jeden der Unit-Typen gibt es Man-Pages – beispielsweise '''systemd.unit '''oder '''systemd.service '''. Über die '''Homepage von Lennart Poettering '''findet man '''zahlreiche Artikel ''', die Hintergründe zum Init-System erläutern, darunter die bislang zwei Teile umfassende Serie "systemd for Developers":* Part I: Socket Activation
| |
| * Part II: Socket Activation (Part II)
| |
| | |
| | |
| | |
| Im '''dritten "Systemd Status Update" '''hat Poettering zudem vor Kurzem einige der Neuerungen aufgelistet, die in den letzten eineinhalb Jahren in Systemd eingeflossen sind.
| |
| | |
| Im '''zweiten Teil des Artikels '''geht es um Systemd aus Adminsicht: Aufbau von Unit-Dateien, Befehle zum Auflisten, Starten und Stoppen von Units, Statusausgaben und Beheben von Problemen.
| |
|
| |
|
| | ===== Man-Page ===== |
| | ===== Info-Pages ===== |
| | ==== Links ==== |
| | ===== Projekt ===== |
| | ===== Weblinks ===== |
|
| |
|
| /lib/systemd/systemd-sysv-install
| | [[Kategorie:systemd]] |
|
| |
|
| [[Category:Linux:Dienstverwaltung]]
| | </noinclude> |
| [[Kategorie:Linux:Systemstart]]
| |