|
|
| (78 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| = Systemd =
| | '''systemd''' - [[Init-System]] und Systemmanager |
| === Einführung ===
| |
| Systemd ist ein Init-System und Systemmanager, der weitgehend zum neuen Standard für Linux-Distributionen geworden ist. Aufgrund seiner starken Verbreitung lohnt es sich, sich mit systemd vertraut zu machen, da es die Administration von Servern erheblich erleichtert. Wenn Sie die Werkzeuge und Daemons, aus denen systemd besteht, kennenlernen und verwenden, werden Sie die Leistungsfähigkeit, Flexibilität und Fähigkeiten, die es bietet, besser zu schätzen wissen oder zumindest ihre Arbeit mit minimalem Aufwand erledigen können.
| |
|
| |
|
| In diesem Leitfaden besprechen wir den Befehl systemctl, bei dem es sich um das zentrale Verwaltungswerkzeug zur Steuerung des Init-Systems handelt. Wir behandeln die Verwaltung von Diensten, die Überprüfung des Status, die Änderung von Systemzuständen und die Arbeit im Umgang mit den Konfigurationsdateien.
| | {| class="wikitable options" |
| | |
| Bitte beachten Sie, dass systemd zwar zum Standard-Init-System für viele Linux-Distributionen geworden ist, aber nicht durchgängig in allen Distributionen implementiert ist. Wenn Ihr Terminal beim Durcharbeiten dieses Tutorials die Fehlermeldung bash: systemctl is not installed ausgibt, ist es wahrscheinlich, dass auf Ihrem Rechner ein anderes Init-System installiert ist.
| |
| | |
| == Dienste verwalten ==
| |
| Der grundlegende Zweck eines Init-Systems ist die Initialisierung der Komponenten, die nach dem Booten des Linux-Kernels gestartet werden müssen (traditionell als „userland“-Komponenten bekannt). Das Init-System wird auch dazu verwendet, Dienste und Daemons für den Server zu jedem Zeitpunkt während des Systembetriebs zu verwalten. Vor diesem Hintergrund beginnen wir mit einigen grundlegenden Operationen zur Verwaltung von Diensten.
| |
| | |
| In systemd sind die meisten Aktionen auf „Einheiten“ (sog. Units) ausgerichtet, wobei es sich um Ressourcen handelt, die systemd verwalten kann. Einheiten werden nach der Art der Ressource, die sie repräsentieren, kategorisiert und mit Dateien definiert, die als Unit-Dateien bekannt sind. Die Art jeder Einheit kann aus dem Suffix am Ende der Datei abgeleitet werden.
| |
| | |
| Für Dienstverwaltungsaufgaben ist die Zieleinheit die Diensteinheiten, die Unit-Dateien mit dem Suffix .service aufweisen. Bei den meisten Dienstverwaltungsbefehlen können Sie jedoch das Suffix .service weglassen, da systemd intelligent genug ist, um zu wissen, dass Sie bei der Verwendung von Dienstverwaltungsbefehlen wahrscheinlich an einem Dienst arbeiten möchten.
| |
| | |
| === Starten und beenden ===
| |
| Um einen systemd-Dienst zu starten, indem Anweisungen in der Unit-Datei des Dienstes ausgeführt werden, verwenden Sie den Befehl start. Wenn Sie als Nicht-root-Benutzer arbeiten, müssen Sie sudo verwenden, da dies den Status des Betriebssystems beeinflusst:
| |
| # ''' systemctl start application.service'''
| |
| | |
| Wie bereits erwähnt, weiß systemd, nach *.service-Dateien für die Dienstverwaltungsbefehle zu suchen, sodass der Befehl auch einfach wie folgt eingegeben werden könnte:
| |
| # ''' systemctl start application'''
| |
| | |
| Obwohl Sie das obige Format für die allgemeine Verwaltung verwenden können, verwenden wir aus Gründen der Übersichtlichkeit für die restlichen Befehle das Suffix .service, um das Ziel, an dem wir arbeiten, explizit zu kennzeichnen.
| |
| | |
| Um einen derzeit laufenden Dienst zu stoppen, können Sie stattdessen den Befehl stop verwenden:
| |
| # ''' systemctl stop application.service'''
| |
| | |
| === Neustarten und Neuladen ===
| |
| Um einen laufenden Dienst neu zu starten, können Sie den Befehl restart verwenden:
| |
| # ''' systemctl restart application.service'''
| |
| | |
| Wenn die betreffende Anwendung ihre Konfigurationsdateien neu laden kann (ohne Neustart), können Sie den Befehl reload erteilen, um diesen Prozess zu starten:
| |
| # ''' systemctl reload application.service'''
| |
| | |
| Wenn Sie nicht sicher sind, ob der Dienst die Funktionalität zum Neuladen seiner Konfiguration hat, können Sie den Befehl reload-or-restart erteilen. Dadurch wird die vorhandene Konfiguration, sofern verfügbar, neu geladen. Andernfalls startet der Befehl den Dienst, sodass die neue Konfiguration abgerufen wird:
| |
| # ''' systemctl reload-or-restart application.service'''
| |
| | |
| === Aktivieren und Deaktivieren von Diensten ===
| |
| Die obigen Befehle sind für das Starten oder Anhalten von Diensten während der aktuellen Sitzung nützlich. Um systemd anzuweisen, Dienste beim Booten automatisch zu starten, müssen Sie sie aktivieren.
| |
| | |
| Um einen Dienst beim Booten zu starten, verwenden Sie den Befehl enable:
| |
| # ''' systemctl enable application.service'''
| |
| | |
| Dadurch wird ein symbolischer Link von der Kopie der Dienst-Datei des Systems (normalerweise in /lib/systemd/system oder /etc/systemd/system) zu dem Speicherort auf Festplatte, wo systemd nach Autostart-Dateien sucht (normalerweise /etc/systemd/system/some_target.target.wants. Wir werden später in diesem Leitfaden darauf eingehen, was ein Ziel (target) ist).
| |
| | |
| Um das automatische Starten des Dienstes zu deaktivieren, können Sie Folgendes eingeben:
| |
| # ''' systemctl disable application.service'''
| |
| | |
| Dadurch wird der symbolische Link entfernt, der angab, dass der Dienst automatisch gestartet werden sollte.
| |
| | |
| Denken Sie daran, dass das Aktivieren eines Dienstes diesen nicht in der aktuellen Sitzung startet. Wenn Sie den Dienst starten und ihn auch beim Booten aktivieren möchten, müssen Sie sowohl den Befehl start als auch den Befehl enable erteilen.
| |
| | |
| === Überprüfen des Status der Dienste ===
| |
| Um den Status eines Dienstes auf Ihrem System zu überprüfen, können Sie den Befehl status verwenden:
| |
| # '''systemctl status application.service'''
| |
| | |
| Dadurch erhalten Sie den Dienststatus, die cgroup-Hierarchie und die ersten paar Protokollzeilen.
| |
| | |
| Wenn Sie beispielsweise den Status eines Nginx-Servers überprüfen, sehen Sie möglicherweise eine Ausgabe wie diese:
| |
| | |
| ● nginx.service - A high performance web server and a reverse proxy server
| |
| Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
| |
| Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
| |
| Main PID: 495 (nginx)
| |
| CGroup: /system.slice/nginx.service
| |
| ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
| |
| └─496 nginx: worker process
| |
| Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
| |
| Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
| |
| | |
| Dadurch erhalten Sie einen schönen Überblick über den aktuellen Status der Anwendung und Sie werden über alle Probleme und eventuell erforderliche Maßnahmen informiert.
| |
| | |
| Es gibt auch Methoden zur Überprüfung bestimmter Zustände. Um beispielsweise zu überprüfen, ob eine Einheit derzeit aktiv ist (läuft), können Sie den Befehl is-active verwenden:
| |
| # '''systemctl is-active application.service'''
| |
| | |
| Dies gibt den aktuellen Zustand der Einheit zurück, der normalerweise active oder inactive ist. Der Exit-Code ist „0“, wenn er aktiv ist, wodurch das Ergebnis in Shell-Skripten einfacher zu parsen ist.
| |
| | |
| Um zu sehen, ob die Einheit aktiviert ist, können Sie den Befehl is-enabled verwenden:
| |
| # '''systemctl is-enabled application.service'''
| |
| | |
| Dies gibt aus, ob der Dienst enabled oder disabled ist und setzt den Exit-Code erneut auf „0“ oder „1“, abhängig von der Antwort auf die Befehlsfrage.
| |
| | |
| Eine dritte Überprüfung ist, ob sich die Einheit in einem fehlerhaften Zustand befindet. Dies deutet darauf hin, dass es ein Problem beim Starten der betreffenden Einheit gab:
| |
| # '''systemctl is-failed application.service'''
| |
| | |
| Dies gibt bei ordnungsgemäßer Ausführung active zurück oder failed, wenn ein Fehler aufgetreten ist. Wurde die Einheit absichtlich angehalten, kann unknown oder inactive zurückgegeben werden. Ein Exit-Status von „0“ gibt an, dass ein Fehler aufgetreten ist, und ein Exit-Status von „1“ zeigt jeden anderen Status an.
| |
| | |
| == Systemstatus ==
| |
| Die bisherigen Befehle haben sich für die Verwaltung einzelner Dienste als nützlich erwiesen, doch sind sie nicht sehr hilfreich, um den aktuellen Zustand des Systems zu untersuchen. Es gibt eine Reihe von systemctl-Befehlen, die diese Informationen bereitstellen.
| |
| | |
| === Auflisten aktueller Einheiten ===
| |
| Um eine Liste aller aktiven Einheiten zu sehen, von denen systemd Kenntnis hat, können wir den Befehl list-units verwenden:
| |
| # '''systemctl list-units'''
| |
| | |
| Dies zeigt eine Liste aller Einheiten, die systemd derzeit im System aktiv hat. Die Ausgabe sieht in etwa folgendermaßen aus:
| |
| UNIT LOAD ACTIVE SUB DESCRIPTION
| |
| atd.service loaded active running ATD daemon
| |
| avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
| |
| dbus.service loaded active running D-Bus System Message Bus
| |
| dcron.service loaded active running Periodic Command Scheduler
| |
| dkms.service loaded active exited Dynamic Kernel Modules System
| |
| getty@tty1.service loaded active running Getty on tty1
| |
| . .
| |
| | |
| Die Ausgabe weist die folgenden Spalten auf:
| |
| * UNIT: der systemd-Einheitenname
| |
| * LOAD: ob die Konfiguration der Einheit durch systemd geparst wurde. Die Konfiguration von geladenen Einheiten wird im Speicher gespeichert.
| |
| * ACTIVE: ein zusammenfassender Status darüber, ob die Einheit aktiv ist. Dies ist normalerweise eine recht einfache Möglichkeit, um festzustellen, ob ie die Einheit erfolgreich gestartet wurde oder nicht.
| |
| * SUB: Dies ist ein untergeordneter Status, der detailliertere Informationen über die Einheit anzeigt. Dies variiert oft nach Art der Einheit, Status und der tatsächlichen Methode, in der die Einheit ausgeführt wird.
| |
| * DESCRIPTION: Eine kurze Textbeschreibung dessen, was die Einheit ist bzw. tut.
| |
| | |
| Da der Befehl list-units standardmäßig nur aktive Einheiten anzeigt, zeigen alle obigen Einträge in der Spalte LOAD loaded und active in der Spalte ACTIVE. Diese Anzeige ist tatsächlich das Standardverhalten von systemctl bei dem Aufruf ohne zusätzliche Befehle. Daher sehen Sie dasselbe, wenn Sie systemctl ohne Argumente aufrufen:
| |
| systemctl
| |
| | |
| Durch Hinzufügen von zusätzlichen Flags können wir systemctl anweisen, andere Informationen auszugeben. Um beispielsweise alle Einheiten zu sehen, die systemd geladen hat (oder versucht hat zu laden), unabhängig davon, ob sie derzeit aktiv sind, können Sie das Flag --all wie folgt verwenden:
| |
| # '''systemctl list-units --all'''
| |
| | |
| Dies zeigt jede Einheit, an, die systemd geladen hat oder versucht hat zu laden, unabhängig von ihrem aktuellen Zustand im System. Einige Einheiten werden nach der Ausführung inaktiv und einige Einheiten, die systemd versucht hat zu laden, wurden möglicherweise nicht auf der Festplatte gefunden.
| |
| | |
| Sie können andere Flags verwenden, um diese Ergebnisse zu filtern. Beispielsweise können wir das Flag --state= verwenden, um die Zustände LOAD, ACTIVE oder SUB anzugeben, die wir sehen möchten. Sie müssen das Flag --all beibehalten, damit systemctl die Anzeige nicht aktiver Einheiten erlaubt:
| |
| # '''systemctl list-units --all --state=inactive'''
| |
| | |
| Ein weiterer gebräuchlicher Filter ist der Filter --type=. Wir können systemctl anweisen, nur Einheiten der Art anzuzeigen, an der wir interessiert sind. Um beispielsweise nur aktive Diensteinheiten zu sehen, können wir verwenden:
| |
| # '''systemctl list-units --type=service'''
| |
| | |
| === Unit-Dateien auflisten ===
| |
| Der Befehl list-units zeigt nur Einheiten an, die systemd versucht hat zu parsen und in den Speicher zu laden. Da systemd nur Einheiten liest, von denen es glaubt, dass sie benötigt werden, beinhaltet dies nicht unbedingt alle verfügbaren Einheiten im System. Um alle verfügbaren Unit-Datei innerhalb der systemd-Pfade anzuzeigen, einschließlich derjenigen, die systemd nicht versucht hat zu laden, können Sie stattdessen den Befehl list-unit-files verwenden:
| |
| # '''systemctl list-unit-files'''
| |
| | |
| Units (Einheiten) sind Repräsentationen von Ressourcen, von denen systemd Kenntnis hat. Da systemd nicht unbedingt alle Unit-Definitionen in dieser Ansicht gelesen hat, zeigt es nur Informationen über die Dateien selbst an. Die Ausgabe hat zwei Spalten: die Unit-Datei und den Zustand.
| |
| | |
| UNIT FILE STATE
| |
| proc-sys-fs-binfmt_misc.automount static
| |
| dev-hugepages.mount static
| |
| dev-mqueue.mount static
| |
| proc-fs-nfsd.mount static
| |
| proc-sys-fs-binfmt_misc.mount static
| |
| sys-fs-fuse-connections.mount static
| |
| sys-kernel-config.mount static
| |
| sys-kernel-debug.mount static
| |
| tmp.mount static
| |
| var-lib-nfs-rpc_pipefs.mount static
| |
| org.cups.cupsd.path enabled
| |
| . .
| |
| | |
| Der Zustand ist in der Regel enabled (aktiviert), disabled (deaktiviert), static (statisch) oder masked (maskiert). In diesem Zusammenhang bedeutet statisch, dass die Unit-Datei keinen Abschnitt install enthält, der zur Aktivierung einer Einheit verwendet wird. Daher können diese Einheiten nicht aktiviert werden. Normalerweise bedeutet dies, dass die Einheit eine einmalige Aktion ausführt oder nur als Abhängigkeit einer anderen Einheit verwendet wird und nicht allein ausgeführt werden sollte.
| |
| | |
| Die Bedeutung von masked werden wir in Kürze besprechen.
| |
| | |
| == Einheiten verwalten ==
| |
| Bisher haben wir mit Diensten gearbeitet und Informationen über die Einheit und die Unit-Dateien angezeigt, von denen systemd Kenntnis hat. Mit einigen zusätzlichen Befehlen können wir jedoch spezifischere Informationen über Einheiten herausfinden.
| |
| | |
| === Unit-Datei anzeigen ===
| |
| Um die Unit-Datei anzuzeigen, die systemd in sein System geladen hat, können Sie den Befehl cat verwenden (dieser wurde in systemd Version 209 hinzugefügt). Um beispielsweise die Unit-Datei des atd Scheduling-Daemons zu sehen, könnten wir Folgendes eingeben:
| |
| | |
| # '''systemctl cat atd.service'''
| |
|
| |
| [Unit]
| |
| Description=ATD daemon
| |
| [Service]
| |
| Type=forking
| |
| ExecStart=/usr/bin/atd
| |
| [Install]
| |
| WantedBy=multi-user.target
| |
| | |
| Die Ausgabe ist die Unit-Datei, die dem aktuell laufenden systemd-Prozess bekannt ist. Dies kann wichtig sein, wenn Sie kürzlich Unit-Dateien geändert haben oder wenn Sie bestimmte Optionen in einem Unit-Dateifragment überschreiben (wir werden dies später behandeln).
| |
| | |
| === Abhängigkeiten anzeigen ===
| |
| Um den Abhängigkeitsbaum einer Einheit anzuzeigen, können Sie den Befehl list-dependencies verwenden:
| |
| # '''systemctl list-dependencies sshd.service'''
| |
| | |
| Dadurch wird eine Hierarchie angezeigt, die die Abhängigkeiten abbildet, die behandelt werden müssen, um die betreffende Einheit zu starten. Abhängigkeiten umfassen in diesem Zusammenhang diejenigen Einheiten, die entweder von darüber liegenden Einheiten benötigt oder gewünscht werden.
| |
| | |
| sshd.service
| |
| ├─system.slice
| |
| └─basic.target
| |
| ├─microcode.service
| |
| ├─rhel-autorelabel-mark.service
| |
| ├─rhel-autorelabel.service
| |
| ├─rhel-configure.service
| |
| ├─rhel-dmesg.service
| |
| ├─rhel-loadmodules.service
| |
| ├─paths.target
| |
| ├─slices.target
| |
| . .
| |
| | |
| Die rekursiven Abhängigkeiten werden nur für .target-Einheiten angezeigt, wobei diese Systemzustände angeben. Um alle Abhängigkeiten rekursiv aufzulisten, fügen Sie das Flag --all hinzu.
| |
| | |
| Um umgekehrte Abhängigkeiten (Einheiten, die von der angegebenen Einheit abhängen) anzuzeigen, können Sie dem Befehl das Flag --reverse hinzufügen. Andere nützliche Flags sind die Flags --before und --after, die zur Anzeige von Einheiten verwendet werden können, die von der angegebenen Einheit abhängen und vor bzw. nach sich selbst beginnen.
| |
| | |
| === Überprüfen der Einheit-Eigenschaften ===
| |
| Um die untergeordneten Eigenschaften einer Einheit zu sehen, können Sie den Befehl show verwenden. Dadurch wird eine Liste der Eigenschaften angezeigt, die für die angegebene Einheit mit dem Format key=value festgelegt werden:
| |
| | |
| # '''systemctl show sshd.service'''
| |
|
| |
| Id=sshd.service
| |
| Names=sshd.service
| |
| Requires=basic.target
| |
| Wants=system.slice
| |
| WantedBy=multi-user.target
| |
| Conflicts=shutdown.target
| |
| Before=shutdown.target multi-user.target
| |
| After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
| |
| Description=OpenSSH server daemon
| |
| . .
| |
| | |
| Wenn Sie eine einzelne Eigenschaft anzeigen möchten, können Sie das Flag -p mit dem Eigenschaftsnamen übergeben. Um beispielsweise die Konflikte zu sehen, die die Einheit sshd.service hat, können Sie Folgendes eingeben:
| |
| # '''systemctl show sshd.service -p Conflicts'''
| |
|
| |
| Conflicts=shutdown.target
| |
| | |
| === Maskieren und Demaskieren von Einheiten ===
| |
| Wir haben im Abschnitt Verwaltung von Diensten gesehen, wie ein Dienst angehalten oder deaktiviert werden kann, aber systemd weist auch die Möglichkeit auf, eine Einheit durch Verknüpfung mit /dev/null automatisch oder manuell als vollständig nicht startbar zu markieren. Dies wird als Maskieren der Einheit bezeichnet und ist mit dem Befehl mask möglich:
| |
| # ''' systemctl mask nginx.service'''
| |
| | |
| Dadurch wird verhindert, dass der Nginx-Dienst automatisch oder manuell gestartet wird, solange er maskiert ist.
| |
| | |
| Wenn Sie die list-unit-files überprüfen, sehen Sie, dass der Dienst nun als maskiert aufgelistet ist:
| |
| | |
| # systemctl list-unit-files
| |
|
| |
| kmod-static-nodes.service static
| |
| ldconfig.service static
| |
| mandb.service static
| |
| messagebus.service static
| |
| nginx.service masked
| |
| quotaon.service static
| |
| rc-local.service static
| |
| rdisc.service disabled
| |
| rescue.service static
| |
| ...
| |
| | |
| Wenn Sie versuchen, den Dienst zu starten, sehen Sie eine Nachricht wie diese:
| |
| # ''' systemctl start nginx.service'''
| |
|
| |
| Failed to start nginx.service: Unit nginx.service is masked.
| |
| | |
| Um eine Einheit zu demaskieren und wieder für die Verwendung verfügbar zu machen, verwenden Sie den Befehl unmask:
| |
| # ''' systemctl unmask nginx.service'''
| |
| | |
| Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann.
| |
| | |
| == Bearbeiten von Unit-Dateien ==
| |
| Während das spezifische Format für Unit-Dateien außerhalb des Rahmens dieses Tutorials liegt, bietet systemctl integrierte Mechanismen für die Bearbeitung und Änderung von Unit-Dateien, falls Sie Anpassungen vornehmen müssen. Diese Funktionalität wurde in systemd Version 218 hinzugefügt.
| |
| | |
| Der Befehl edit öffnet standardmäßig eine Unit-Datei für die betreffende Einheit.
| |
| # ''' systemctl edit nginx.service'''
| |
| | |
| Dabei handelt es sich um eine leere Datei, die zum Überschreiben oder Hinzufügen von Anweisungen zu Unit-Definition verwendet werden kann. Innerhalb des Verzeichnisses /etc/systemd/system wird ein Verzeichnis erstellt, das den Namen der Einheit mit angehängtem .d enthält. Für den nginx.service wird beispielsweise ein Verzeichnis namens nginx.service.d erstellt.
| |
| | |
| Innerhalb dieses Verzeichnisses wird ein Snippet namens override.conf erstellt. Wenn die Einheit geladen ist, führt systemd das Überschreiben-Snippet im Speicher mit der vollständigen Unit-Datei zusammen. Die Anweisungen des Snippets haben Vorrang vor denen, die in der ursprünglichen Unit-Datei zu finden sind.
| |
| | |
| Wenn Sie die vollständige Unit-Datei bearbeiten möchten, anstatt einen Snippet zu erstellen, können Sie das Flag --full übergeben:
| |
| # ''' systemctl edit --full nginx.service'''
| |
| | |
| Dadurch wird die aktuelle Unit-Datei in den Editor geladen, wo sie geändert werden kann. Wird der Editor verlassen, wird die geänderte Datei in /etc/systemd/system geschrieben, wobei diese Datei Vorrang vor der Unit-Definition des Systems hat (normalerweise irgendwo in /lib/systemd/system zu finden).
| |
| | |
| Um alle von Ihnen vorgenommenen Ergänzungen zu entfernen, löschen Sie entweder das Konfigurationsverzeichnis .d der Einheit oder die geänderte Dienst-Datei aus /etc/systemd/system. Um beispielsweise ein Snippet zu entfernen, können wir Folgendes eingeben:
| |
| # ''' rm -r /etc/systemd/system/nginx.service.d'''
| |
| | |
| Um eine vollständige geänderte Unit-Datei zu entfernen, geben wir Folgendes ein:
| |
| # ''' rm /etc/systemd/system/nginx.service'''
| |
| | |
| Nach dem Löschen der Datei oder des Verzeichnisses sollten Sie den Prozess systemd neu laden, sodass er nicht mehr versucht, auf diese Dateien zu verweisen und wieder die Systemkopie verwendet. Geben Sie dazu Folgendes ein:
| |
| # ''' systemctl daemon-reload'''
| |
| | |
| == Anpassen des Systemzustands (Runlevel) mit Zielen ==
| |
| Ziele sind spezielle Unit-Dateien, die einen Systemzustand oder Synchronisationspunkt beschreiben. Wie andere Einheiten können die Dateien, die Ziele definieren, durch ihr Suffix identifiziert werden, was in diesem Fall .target ist. Ziele machen selbst nicht viel, sondern werden stattdessen verwendet, um andere Einheiten zusammenzufassen.
| |
| | |
| Dies kann verwendet werden, um das System in bestimmte Zustände zu bringen, ähnlich wie andere Init-Systeme Runlevel verwenden. Sie werden als Referenz verwendet, wenn bestimmte Funktionen verfügbar sind, sodass Sie anstelle der einzelnen Einheiten, die zur Erzeugung dieses Zustands benötigt werden, den gewünschten Zustand angeben können.
| |
| | |
| Beispielsweise gibt es ein swap.target, das verwendet, um anzugeben, dass Swap einsatzbereit ist. Einheiten, die Teil dieses Prozesses sind, können mit diesem Ziel synchronisieren, indem sie in ihrer Konfiguration angeben, dass sie WantedBy= oder RequiredBy= vom swap.target sind. Einheiten, für die Swap verfügbar sein muss, können diese Bedingung mit den Spezifikationen Wants=, Requires= und After= angeben, um die Art ihrer Beziehung anzugeben.
| |
| | |
| === Abrufen und Einrichten des Standardziels ===
| |
| Der Prozess systemd hat ein Standardziel, das er beim Booten des Systems verwendet. Die Befriedigung der Kaskade von Abhängigkeiten von diesem einzelnen Ziel bringt das System in den gewünschten Zustand. Um das Standardziel für Ihr System zu finden, geben Sie Folgendes ein:
| |
| | |
| # '''systemctl get-default'''
| |
| | |
| multi-user.target
| |
| | |
| Wenn Sie ein anderes Standardziel festlegen möchten, können Sie set-default verwenden. Wenn Sie beispielsweise eine grafische Arbeitsoberfläche installiert haben und möchten, dass das System standardmäßig in diese bootet, können Sie Ihr Standardziel entsprechend ändern:
| |
| # ''' systemctl set-default graphical.target'''
| |
| | |
| === Auflisten verfügbarer Ziele ===
| |
| Sie können eine Liste der auf Ihrem System verfügbaren Ziele erhalten, indem Sie Folgendes eingeben:
| |
| # '''systemctl list-unit-files --type=target'''
| |
| | |
| Im Gegensatz zu Runleveln können mehrere Ziele gleichzeitig aktiv sein. Ein aktives Ziel gibt an, dass systemd versucht hat, alle an das Ziel gebundene Einheiten zu starten und nicht versucht hat, sie wieder zu entfernen. Um alle aktiven Ziele zu sehen, geben Sie Folgendes ein:
| |
| # '''systemctl list-units --type=target'''
| |
| | |
| === Isolieren von Zielen ===
| |
| Es ist möglich, alle mit einem Ziel verknüpften Einheiten zu starten und alle Einheiten zu stoppen, die nicht Teil des Abhängigkeitsbaums sind. Der Befehl, den wir dazu benötigen, heißt entsprechend isolate. Dies ist ähnlich wie das Ändern der Runlevel in anderen Init-Systemen.
| |
| | |
| Wenn Sie beispielsweise in einer grafischen Umgebung mit aktivem graphical.target arbeiten, können Sie das grafische System herunterfahren und das System in einen Multibenutzer-Befehlszeilenzustand versetzen, indem Sie multi-user.target isolieren. Da graphical.target von multi-user.target abhängt, aber nicht umgekehrt, werden alle grafischen Einheiten angehalten.
| |
| | |
| Sie sollten sich vor der Durchführung dieses Vorgangs die Abhängigkeiten des zu isolierenden Ziels ansehen, um sicherzustellen, dass Sie keine wichtigen Dienste anhalten.
| |
| # '''systemctl list-dependencies multi-user.target'''
| |
| | |
| Wenn Sie mit den Einheiten, die weiterhin aktiv bleiben sollen, zufrieden sind, können Sie das Ziel isolieren, indem Sie Folgendes eingeben:
| |
| # ''' systemctl isolate multi-user.target'''
| |
| | |
| === Verwenden von Shortcuts für wichtige Ereignisse ===
| |
| Es gibt Ziele, die für wichtige Ereignisse wie Ausschalten oder Neustart definiert sind. Allerdings verfügt systemctl auch über einige Shortcuts, die einige zusätzliche Funktionalität hinzufügen.
| |
| | |
| Um beispielsweise das System in den (Einzelbenutzer) Rettungsmodus zu versetzen, können Sie einfach den Befehl rescue verwenden, anstatt isolate rescue.target.
| |
| # ''' systemctl rescue'''
| |
| | |
| Dies bietet die zusätzliche Funktionalität, alle angemeldeten Benutzer über das Ereignis zu alarmieren.
| |
| | |
| Um das System anzuhalten, können Sie den Befehl halt verwenden:
| |
| # ''' systemctl halt'''
| |
| | |
| Um eine vollständiges Herunterfahren einzuleiten, können Sie den Befehl poweroff verwenden:
| |
| # ''' systemctl poweroff'''
| |
| | |
| Ein Neustart kann mit dem Befehl reboot gestartet werden:
| |
| # ''' systemctl reboot'''
| |
| | |
| Diese alarmieren angemeldete Benutzer, dass das Ereignis auftritt, was nur durch Ausführen oder Isolieren des Ziels nicht möglich ist. Zu beachten ist, dass die meisten Rechner die kürzeren, konventionelleren Befehle für diese Operationen verknüpfen, damit sie ordnungsgemäß mit systemd arbeiten.
| |
| | |
| Um beispielsweise das System neu zu starten, können Sie normalerweise eingeben:
| |
| # ''' reboot'''
| |
| | |
| https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de
| |
| | |
| = Der Daemon systemd =
| |
| Das Programm <tt>systemd</tt> trägt die Prozess-ID Hiermit wird das System in der erforderlichen Form initialisiert. <tt>systemd</tt> wird direkt vom Kernel gestartet und widersteht dem Signal 9, das in der Regel Prozesse beendet. Alle anderen Programme werden entweder direkt von systemd oder von einem seiner untergeordneten Prozesse gestartet.
| |
| | |
| Systemd ersetzt den System V init-Daemon. <tt>systemd</tt> ist mit System V init uneingeschränkt kompatibel (init-Skripten werden unterstützt). Einer der wichtigsten Vorteile von systemd ist die deutliche Beschleunigung des Bootvorgangs, da die Dienststarts konsequent parallel ausgeführt werden. Darüber hinaus startet systemd einen Dienst nur dann, wenn er tatsächlich benötigt wird. Deamons werden nicht in jedem Fall beim Booten gestartet, sondern erst dann, wenn sie erstmalig benötigt werden. systemd unterstützt außerdem Kernel-Steuergruppen (cgroups), das Erstellen von Snapshots, das Wiederherstellen des Systemstatus und vieles mehr. Weitere Informationen finden Sie in [http://www.freedesktop.org/wiki/Software/systemd/ http://www.freedesktop.org/wiki/Software/systemd/].
| |
| | |
| == Konzept ==
| |
| === Grundlagen von systemd ===
| |
| systemd ist ein System- und Sitzungsmanager für Linux und ist mit System V- und LSB-init-Skripts kompatibel. Die wichtigsten Funktionen sind: * Konsequente Parallelisierung
| |
| * Starten von Diensten per Socket- und D-Bus-Aktivierung
| |
| * Starten der Daemons bei Bedarf
| |
| * Verfolgen der Prozesse, die Linux-cgroups nutzen
| |
| * Unterstützung für das Erstellen von Snapshots und Wiederherstellen des Systemstatus
| |
| * Einhängepunkte und Automount-Punkte
| |
| * Ausgereifte Dienststeuerlogik auf der Basis der Transaktionsabhängigkeiten
| |
| | |
| === Unit-Datei ===
| |
| Eine Unit-Konfigurationsdatei enthält Informationen zu einem Dienst, Socket, Gerät, Einhängepunkt, Automount-Punkt, einer Auslagerungsdatei oder Partition, einem Startziel, einem überwachten Dateisystempfad, einem von systemd gesteuerten und überwachten Zeitgeber, einem Snapshot eines temporären Systemstatus, einem Ressourcenverwaltungs-Slice oder einer Gruppe extern erstellter Prozesse. „Unit-Datei“ ist in systemd ein generischer Term für Folgendes: * Dienst. Informationen zu einem Prozess (z. B. Ausführung eines Daemon); Datei endet auf .service
| |
| * Ziele. Fassen Units zu Gruppen zusammen bzw. fungieren als Synchronisierungspunkte beim Starten; Datei endet auf .target
| |
| * Sockets. Informationen zu einem IPC- oder Netzwerk-Socket oder einem Dateisystem-FIFO, für die socketbasierte Aktivierung (wie <tt>inetd</tt>); Datei endet auf .socket
| |
| * Pfad. Dient als Auslöser von anderen Units (z. B. Ausführen eines Dienstes, wenn Dateien geändert werden); Datei endet auf .path
| |
| * Zeitgeber. Informationen zu einem gesteuerten Zeitgeber für die zeitgeberbasierte Aktivierung; Datei endet auf .timer
| |
| * Einhängepunkt. In der Regel automatisch durch den fstab-Generator erzeugt; Datei endet auf .mount
| |
| * Automount-Punkt. Informationen zu einem Dateisystem-Automount-Punkt; Datei endet auf .automount
| |
| * Swap. Informationen zu einem Auslagerungsgerät oder einer Auslagerungsdatei für das Arbeitsspeicher-Paging; Datei endet auf .swap
| |
| * Gerät. Informationen zu einer Geräte-Unit in der Geräte-Baumstruktur sysfs/udev(7); Datei endet auf .device
| |
| * Bereich/Slice. Konzept für die hierarchische Verwaltung von Ressourcen einer Prozessgruppe; Datei endet auf .scope/.slice
| |
| | |
| Weitere Informationen zu systemd.unit finden Sie unter [http://www.freedesktop.org/software/systemd/man/systemd.unit.html http://www.freedesktop.org/software/systemd/man/systemd.unit.html].
| |
| | |
| == Grundlegende Verwendung ==
| |
| Im System V-init-System werden Dienste mit mehreren Kommandos verarbeitet – mit init-Skripten, <tt>insserv</tt>, <tt>telinit</tt> und anderen. systemd erleichtert die Dienstverwaltung, da ein einziges Kommando die meisten Dienstverarbeitungsaufgaben abdeckt: <tt>systemctl</tt>. Hierbei gilt die Syntax „Kommando plus Subkommando“ wie bei <tt>git</tt> oder <tt>zypper</tt>:
| |
| | |
| systemctl ''GENERAL OPTIONS'' ''SUBCOMMAND'' ''SUBCOMMAND OPTIONS''
| |
| | |
| Vollständige Anweisungen finden Sie in <tt>man 1 systemctl</tt>.
| |
| | |
| ====== Tipp: Terminalausgabe und Bash-Vervollständigung ======
| |
| Wenn die Ausgabe an ein Terminal geht (und nicht an eine Pipe oder Datei usw.), senden die systemd-Kommandos standardmäßig eine ausführliche Ausgabe an einen Pager. Mit der Option <tt>--no-pager</tt> deaktivieren Sie den Paging-Modus.
| |
| | |
| systemd unterstützt außerdem die Bash-Vervollständigung. Hierbei geben Sie die ersten Buchstaben eines Subkommandos ein und drücken dann →|, um es automatisch zu vervollständigen. Diese Funktion ist nur in der <tt>Bash</tt>-Shell verfügbar und das Paket <tt>bash-completion</tt> muss installiert sein.
| |
| | |
| === Verwalten von Diensten auf einem laufenden System ===
| |
| Die Subkommandos zum Verwalten der Dienste sind mit den entsprechenden Kommandos in System V-init identisch (<tt>start</tt>, <tt>stop</tt> usw.). Die allgemeine Syntax für Dienstverwaltungskommandos lautet wie folgt:
| |
| | |
| systemd
| |
| systemctl reload|restart|start|status|stop|''...'' ''MY_SERVICE(S)''
| |
| | |
| System V-init
| |
| rc''MY_SERVICE(S)'' reload|restart|start|status|stop|''...''
| |
| | |
| Mit systemd können Sie mehrere Dienste gleichzeitig verwalten. Im Gegensatz zu System V-init, bei dem die init-Skripts einzeln nacheinander ausgeführt werden, führen Sie ein einziges Kommando aus, beispielsweise:
| |
| # '''systemctl start ''MY_1ST_SERVICE'' ''MY_2ND_SERVICE'''''
| |
| | |
| So rufen Sie eine Liste aller auf dem System verfügbaren Dienste ab:
| |
| # '''sudo systemctl list-unit-files --type=service'''
| |
| | |
| Die folgende Tabelle zeigt die wichtigsten Dienstverwaltungskommandos für systemd und System V-init:
| |
| | |
| ====== Befehle zur Diensteverwaltung [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.6.6.9 #] ======
| |
| {|class="wikitable sortable" | |
| |-
| |
| | | '''Aufgabe '''
| |
| | | '''systemd-Kommando '''
| |
| | | '''System V-init-Kommando '''
| |
| |-
| |
| | | Starten.
| |
| | | start
| |
| | | start
| |
| |-
| |
| | | Stoppen.
| |
| | | stop
| |
| | | stop
| |
| |-
| |
| || Neu starten. Fährt Dienste herunter und startet sie dann neu. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet.
| |
| || restart
| |
| || restart
| |
| |-
| |
| || Bedingt neu starten. Startet Dienste neu, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden.
| |
| || try-restart
| |
| || try-restart
| |
| |-
| |
| || Neu laden. Weist die Dienste an, die Konfigurationsdateien neu zu laden ohne die laufenden Vorgänge zu unterbrechen. Anwendungsbeispiel: Weisen Sie Apache an, eine bearbeitete Konfigurationsdatei <tt>httpd.conf</tt> neu zu laden. Nicht alle Dienste unterstützen das Neuladen.
| |
| || reload
| |
| || reload
| |
| |-
| |
| || Neu laden oder neu starten. Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet.
| |
| || reload-or-restart
| |
| || n/a
| |
| |-
| |
| || Bedingt neu laden oder neu starten. Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden.
| |
| || reload-or-try-restart
| |
| || n/a
| |
| |-
| |
| || Ausführliche Statusinformationen abrufen. Zeigt Informationen zum Dienststatus. Das Kommando <tt>systemd</tt> bietet Details wie Beschreibung, ausführbare Datei, Status, cgroup und zuletzt durch den Dienst ausgegebene Meldungen (siehe [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-basics-services-debugging Abschnitt 13.6.8, „Fehlersuche für Dienste“]). Die Detailtiefe bei System V-init ist von Dienst zu Dienst unterschiedlich.
| |
| || status
| |
| || status
| |
| |-
| |
| || Kurze Statusinformationen abrufen. Gibt an, ob Dienste aktiv sind oder nicht.
| |
| || is-active
| |
| || status
| |
| |-
| |
| |}
| |
| | |
| === Dienste dauerhaft aktivieren/deaktivieren ===
| |
| Mit den Dienstverwaltungskommandos im vorangegangenen Abschnitt können Sie die Dienste für die aktuelle Sitzung bearbeiten. Mit systemd können Sie Dienste außerdem dauerhaft aktivieren oder deaktivieren, so dass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Sie können dies mithilfe von YaST oder über die Kommandozeile tun.
| |
| | |
| ==== Aktivieren/Deaktivieren von Diensten über die Kommandozeile ====
| |
| Die folgende Tabelle zeigt die wichtigsten Aktivierungs- und Deaktivierungskommandos für systemd und System V-init:
| |
| | |
| ====== Wichtig: Service starten ======
| |
| Wenn ein Dienst über die Kommandozeile aktiviert wird, wird er nicht automatisch gestartet. Der Dienst wird beim nächsten Systemstart oder bei der nächsten Änderung des Runlevels/Ziels gestartet. Soll ein Dienst nach dem Aktivieren sofort gestartet werden, führen Sie explizit <tt>systemctl start ''MEIN_DIENST''</tt> oder <tt>rc ''MEIN_DIENST'' start</tt> aus.
| |
| | |
| ====== Kommandos zum Aktivieren und Deaktivieren von Diensten [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.6.7.3.4 #] ======
| |
| {|class="wikitable sortable"
| |
|
| |
| |-
| |
| | | '''Aufgabe '''
| |
| | | <tt>'''systemd-Kommando</tt> '''
| |
| | | '''System V-init-Kommando '''
| |
| |-
| |
| | | Aktivieren.
| |
| | | <tt>systemctl enable ''MEIN(E)_DIENST(E)''</tt>
| |
| | | <tt>insserv ''MEIN(E)_DIENST(E)''</tt>, <tt>chkconfig -a ''MEIN(E)_DIENST(E)''</tt>
| |
| |-
| |
| || Deaktivieren.
| |
| || <tt>systemctl disable ''MEIN(E)_DIENST(E)''.service</tt>
| |
| || <tt>insserv -r ''MEIN(E)_DIENST(E)''</tt>, <tt>chkconfig -d ''MEIN(E)_DIENST(E)''</tt>
| |
| |-
| |
| || Überprüfen. Zeigt an, ob ein Dienst aktiviert ist oder nicht.
| |
| || <tt>systemctl is-enabled ''MEIN_DIENST''</tt>
| |
| || <tt>chkconfig ''MEIN_DIENST''</tt>
| |
| |-
| |
| || Erneut aktivieren. Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieses Kommando einen Dienst und aktiviert ihn dann wieder. Nützlich, wenn ein Dienst mit den Standardeinstellungen erneut aktiviert werden soll.
| |
| || <tt>systemctl reenable ''MEIN_DIENST''</tt>
| |
| || n/v
| |
| |-
| |
| || Maskierung. Nach dem „Deaktivieren“ eines Dienstes kann er weiterhin manuell aktiviert werden. Soll ein Dienst vollständig deaktiviert werden, maskieren Sie ihn. Mit Vorsicht verwenden.
| |
| || <tt>systemctl mask ''MEIN_DIENST''</tt>
| |
| || n/v
| |
| |-
| |
| || Demaskieren. Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde.
| |
| || <tt>systemctl unmask ''MEIN_DIENST''</tt>
| |
| || n/v
| |
| |-
| |
| |}
| |
| | |
| == Systemstart und Zielverwaltung ==
| |
| Der gesamte Vorgang des Startens und Herunterfahrens des Systems wird von systemd verwaltet. Von diesem Gesichtspunkt aus kann der Kernel als Hintergrundprozess betrachtet werden, der alle anderen Prozesse verwaltet und die CPU-Zeit sowie den Hardwarezugriff entsprechend den Anforderungen anderer Programme anpasst.
| |
| | |
| === Ziele im Vergleich zu Runlevels ===
| |
| Bei System V-init wurde das System in ein sogenanntes „Runlevel“ gebootet. Ein Runlevel definiert, wie das System gestartet wird und welche Dienste im laufenden System verfügbar sind. Die Runlevels sind numeriert. Die bekanntesten Runlevels sind <tt>0</tt> (System herunterfahren), <tt>3</tt> (Mehrbenutzermodus mit Netzwerk) und <tt>5</tt> (Mehrbenutzermodus mit Netzwerk und Anzeigemanager).
| |
| | |
| systemd führt mit den sogenannten „Ziel-Units“ ein neues Konzept ein. Dennoch bleibt die Kompatibilität mit dem Runlevel-Konzept uneingeschränkt erhalten. Die Ziel-Units tragen Namen statt Zahlen und erfüllen bestimmte Zwecke. Mit den Zielen <tt>local-fs.target</tt> und <tt>swap.target</tt> werden beispielsweise lokale Dateisysteme und Auslagerungsbereiche eingehängt.
| |
| | |
| Das Ziel <tt>graphical.target</tt> stellt ein Mehrbenutzersystem mit Netzwerk sowie Anzeigemanager-Funktionen bereit und entspricht Runlevel Komplexe Ziele wie <tt>graphical.target</tt> fungieren als „Metaziele“, in denen eine Teilmenge anderer Ziele vereint ist. Mit systemd können Sie problemlos vorhandene Ziele kombinieren und so benutzerdefinierte Ziele bilden. Damit bietet dieses Kommando eine hohe Flexibilität.
| |
| | |
| Die nachfolgende Liste zeigt die wichtigsten systemd-Ziel-Units. Eine vollständige Liste finden Sie in <tt>man 7 systemd.special</tt>.
| |
| | |
| ====== Ausgewählte systemd-Ziel-Units [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.3.6 #] ======
| |
| <tt>default.target</tt>
| |
| | |
| Das Ziel, das standardmäßig gebootet wird. Kein „reales“ Ziel, sondern ein symbolischer Link zu einem anderen Ziel wie <tt>graphic.target</tt>. Kann über YaST dauerhaft geändert werden (siehe [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-runlevel-edit Abschnitt 13.4, „Verwalten von Services mit YaST“]). Soll das Ziel für eine einzige Sitzung geändert werden, geben Sie den Kernel-Parameter <tt>systemd.unit=''MEIN_ZIEL.target''</tt> am Bootprompt ein.
| |
| | |
| <tt>emergency.target</tt>
| |
| | |
| Startet eine Notfall-Shell über die Konsole. Dieses Kommando darf nur an der Boot-Eingabeaufforderung im Format <tt>systemd.unit=emergency.target</tt> verwendet werden.
| |
| | |
| <tt>graphical.target</tt>
| |
| | |
| Startet ein System mit Netzwerk, Mehrbenutzerunterstützung und Anzeigemanager.
| |
| | |
| <tt>halt.target</tt>
| |
| | |
| Fährt das System herunter.
| |
| | |
| <tt>mail-transfer-agent.target</tt>
| |
| | |
| Startet alle Dienste, die zum Senden und Empfangen von Mails erforderlich sind.
| |
| | |
| <tt>multi-user.target</tt>
| |
| | |
| Startet ein Mehrbenutzersystem mit Netzwerk.
| |
| | |
| <tt>reboot.target</tt>
| |
| | |
| Bootet das System neu.
| |
| | |
| <tt>rescue.target</tt>
| |
| | |
| Startet ein Einzelbenutzersystem ohne Netzwerk.
| |
| | |
| Damit die Kompatibilität mit dem Runlevel-System von System V-init gewährleistet bleibt, bietet systemd besondere Ziele mit der Bezeichnung <tt>runlevel''X''.target</tt>, denen die entsprechenden, mit ''X'' numerierten Runlevels zugeordnet sind.
| |
| | |
| Mit dem Kommando <tt>systemctl get-default</tt> ermitteln Sie das aktuelle Ziel.
| |
| | |
| ====== System V-Runlevels und systemd-Ziel-Units [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.3.9 #] ======
| |
| {|class="wikitable sortable"
| |
| |-
| |
| | | '''System V-Runlevel '''
| |
| | | <tt>'''systemd</tt>-Ziel '''
| |
| | | '''Beschreibung '''
| |
| |-
| |
| || 0
| |
| || <tt>runlevel0.target</tt>, <tt>halt.target</tt>, <tt>poweroff.target</tt>
| |
| || System herunterfahren
| |
| |-
| |
| || 1, S
| |
| || <tt>runlevel1.target</tt>, <tt>rescue.target</tt>,
| |
| || Einzelbenutzermodus
| |
| |-
| |
| || 2
| |
| || <tt>runlevel2.target</tt>, <tt>multi-user.target</tt>,
| |
| || Lokaler Mehrbenutzermodus ohne entferntes Netzwerk
| |
| |-
| |
| || 3
| |
| || <tt>runlevel3.target</tt>, <tt>multi-user.target</tt>,
| |
| || Mehrbenutzer-Vollmodus mit Netzwerk
| |
| |-
| |
| || 4
| |
| || <tt>runlevel4.target</tt>
| |
| || Nicht verwendet/benutzerdefiniert
| |
| |-
| |
| || 5
| |
| || <tt>runlevel5.target</tt>, <tt>graphical.target</tt>,
| |
| || Mehrbenutzer-Vollmodus mit Netzwerk und Anzeige-Manager
| |
| |-
| |
| || 6
| |
| || <tt>runlevel6.target</tt>, <tt>reboot.target</tt>,
| |
| || Systemneustart
| |
| |-
| |
| |}
| |
| | |
| ====== Wichtig: systemd ignoriert /etc/inittab ======
| |
| Die Runlevels in einem System V-init-System werden in <tt>/etc/inittab</tt> konfiguriert. Bei systemd wird diese Konfiguration ''nicht'' verwendet. Weitere Anweisungen zum Erstellen eines bootfähigen Ziels finden Sie unter [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-custom-targets Abschnitt 13.5.3, „Erstellen von benutzerdefinierten Zielen“].
| |
| | |
| ==== Kommandos zum Ändern von Zielen ====
| |
| Mit den folgenden Kommandos arbeiten Sie mit den Ziel-Units:
| |
| | |
| {|class="wikitable sortable"
| |
| |-
| |
| | | '''Aufgabe '''
| |
| | | '''systemd-Kommando '''
| |
| | | '''System V-init-Kommando '''
| |
| |- | | |- |
| | | Aktuelles Ziel/Runlevel ändern | | | Beschreibung || [[Systemd/Beschreibung]] |
| | | <tt>systemctl isolate</tt> ''MEIN_ZIEL''.target
| |
| | | <tt>telinit</tt> ''X''
| |
| |-
| |
| | | Zum standardmäßigen Ziel/Runlevel wechseln
| |
| | | <tt>systemctl default</tt>
| |
| | | n/v
| |
| |- | |
| | | Aktuelles Ziel/Runlevel abrufen
| |
| | | <tt>systemctl list-units --type=target</tt>
| |
| | |
| Bei systemd sind in der Regel mehrere Ziele aktiv. Mit diesem Kommando werden alle derzeit aktiven Ziele aufgelistet.
| |
| | | <tt>who -r</tt>
| |
| | |
| oder
| |
| | |
| <tt>runlevel</tt>
| |
| |- | | |- |
| | | Standard-Runlevel dauerhaft ändern | | | Installation || [[Systemd/Installation]] |
| | | Verwenden Sie die Dienste-Verwaltung, oder führen Sie das folgende Kommando aus: | |
| | |
| <tt>ln -sf /usr/lib/systemd/system/</tt> ''MEIN_ZIEL''.target /etc/systemd/system/default.target
| |
| | | Verwenden Sie die Dienste-Verwaltung, oder ändern Sie die Zeile
| |
| | |
| <tt>id:</tt> ''X'':initdefault:
| |
| | |
| in <tt>/etc/inittab</tt>
| |
| |-
| |
| || Standard-Runlevel für den aktuellen Bootprozess ändern
| |
| || Geben Sie an der Boot-Eingabeaufforderung die folgende Option ein:
| |
| | |
| <tt>systemd.unit=</tt> ''MEIN_ZIEL''.target
| |
| || Geben Sie an der Boot-Eingabeaufforderung die gewünschte Runlevel-Nummer ein.
| |
| |-
| |
| || Abhängigkeiten für ein Ziel/Runlevel anzeigen
| |
| || <tt>systemctl show -p "Requires" </tt>''MEIN_ZIEL''.target
| |
| | |
| <tt>systemctl show -p "Wants" </tt>''MEIN_ZIEL''.target
| |
| | |
| „Requires“ (Benötigt) zeigt eine Liste der harten Abhängigkeiten (die in jedem Fall aufgelöst werden müssen), „Wants“ (Erwünscht) dagegen eine Liste der weichen Abhängigkeiten (die nach Möglichkeit aufgelöst werden).
| |
| || n/v
| |
| |- | | |- |
| |} | | | Syntax || [[Systemd/Syntax]] |
| | |
| === Fehlersuche beim Systemstart ===
| |
| systemd bietet eine Möglichkeit, den Systemstartvorgang zu analysieren. Sie können die Liste der Dienste mit dem jeweiligen Status prüfen (ohne durch <tt>/varlog/</tt> blättern zu müssen). Mit systemd können Sie zudem den Startvorgang scannen und so ermitteln, wie lang das Starten der einzelnen Dienste dauert.
| |
| | |
| ==== Prüfen des Startvorgangs der Dienste ====
| |
| Mit dem Kommando <tt>systemctl</tt> erzeugen Sie eine Liste aller Dienste, die seit dem Booten des Systems gestartet wurden. Hier werden alle aktiven Dienste wie im nachstehenden (gekürzten) Beispiel aufgeführt. Mit <tt>systemctl status ''MEIN_DIENST''</tt> erhalten Sie weitere Informationen zu einem bestimmten Dienst.
| |
| | |
| ====== Liste der aktiven Dienste [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.4.3.3 #] ======
| |
| # '''systemctl''' | |
| UNIT LOAD ACTIVE SUB JOB DESCRIPTION
| |
| [...]
| |
| iscsi.service loaded active exited Login and scanning of iSC+
| |
| kmod-static-nodes.service loaded active exited Create list of required s+
| |
| libvirtd.service loaded active running Virtualization daemon
| |
| nscd.service loaded active running Name Service Cache Daemon
| |
| chronyd.service loaded active running NTP Server Daemon
| |
| polkit.service loaded active running Authorization Manager
| |
| postfix.service loaded active running Postfix Mail Transport Ag+
| |
| rc-local.service loaded active exited /etc/init.d/boot.local Co+
| |
| rsyslog.service loaded active running System Logging Service
| |
| [...]
| |
| LOAD = Reflects whether the unit definition was properly loaded.
| |
| ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
| |
| SUB = The low-level unit activation state, values depend on unit type.
| |
| | |
| 161 loaded units listed. Pass --all to see loaded but inactive units, too.
| |
| To show all installed unit files use 'systemctl list-unit-files'.
| |
| | |
| Soll die Ausgabe auf Dienste beschränkt werden, die nicht gestartet werden konnten, geben Sie die Option <tt>--failed</tt> an:
| |
| | |
| ====== Liste der fehlerhaften Dienste [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.7.4.3.5 #] ======
| |
| # '''systemctl --failed'''
| |
| UNIT LOAD ACTIVE SUB JOB DESCRIPTION
| |
| apache2.service loaded failed failed apache
| |
| NetworkManager.service loaded failed failed Network Manager
| |
| plymouth-start.service loaded failed failed Show Plymouth Boot Screen
| |
| | |
| [...]
| |
| | |
| ==== Fehlersuche für die Startzeit ====
| |
| Mit dem Kommando <tt>systemd-analyze</tt> führen Sie die Fehlersuche für die Startzeit durch. Hiermit werden der Gesamtzeitaufwand für den Startvorgang sowie eine Liste der beim Starten angeforderten Dienste angezeigt. Auf Wunsch kann auch eine SVG-Grafik erstellt werden, aus der hervorgeht, wie lange der Start der Dienste im Vergleich zu den anderen Diensten dauerte.
| |
| | |
| Auflisten der Startzeit des Systems
| |
| | |
| # '''systemd-analyze'''
| |
| Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
| |
| | |
| Auflisten der Startzeit der Dienste
| |
| | |
| root # systemd-analyze blame
| |
| 6472ms systemd-modules-load.service
| |
| 5833ms remount-rootfs.service
| |
| 4597ms network.service
| |
| 4254ms systemd-vconsole-setup.service
| |
| 4096ms postfix.service
| |
| 2998ms xdm.service
| |
| 2483ms localnet.service
| |
| 2470ms SuSEfirewall2_init.service
| |
| 2189ms avahi-daemon.service
| |
| 2120ms systemd-logind.service
| |
| 1080ms chronyd.service
| |
| [...]
| |
| 75ms fbset.service
| |
| 72ms purge-kernels.service
| |
| 47ms dev-vda1.swap
| |
| 38ms bluez-coldplug.service
| |
| 35ms splash_early.service
| |
| | |
| Grafische Darstellung der Startzeit der Dienste
| |
| | |
| # '''systemd-analyze plot > jupiter.example.com-startup.svg'''
| |
| | |
| ==== Prüfen des gesamten Startvorgangs ====
| |
| Mit den obigen Kommandos prüfen Sie die gestarteten Dienste und den Zeitaufwand für den Start. Wenn Sie detailliertere Informationen benötigen, können Sie <tt>systemd</tt> anweisen, den gesamten Startvorgang ausführlich zu protokollieren. Geben Sie hierzu die folgenden Parameter an der Boot-Eingabeaufforderung ein:
| |
| | |
| systemd.log_level=debug systemd.log_target=kmsg
| |
| | |
| <tt>systemd</tt> schreibt die Protokollmeldungen nunmehr in den Kernel-Ringpuffer. Diesen Puffer zeigen Sie mit <tt>dmesg</tt> an:
| |
| | |
| $ '''dmesg -T | less'''
| |
| | |
| === System V-Kompatibilität ===
| |
| systemd ist mit System V kompatibel, sodass Sie vorhandene System V-init-Skripte weiterhin nutzen können. Es gibt allerdings mindestens ein bekanntes Problem, bei dem ein System V-init-Skript nicht ohne Weiteres mit systemd zusammenarbeitet: Wenn Sie einen Dienst als ein anderer Benutzer über <tt>su</tt> oder <tt>sudo</tt> in init-Skripten starten, tritt der Fehler „Access denied“ (Zugriff verweigert) auf.
| |
| | |
| Wenn Sie den Benutzer mit <tt>su</tt> oder <tt>sudo</tt> ändern, wird eine PAM-Sitzung gestartet. Diese Sitzung wird beendet, sobald das init-Skript abgeschlossen ist. Als Folge wird auch der Service, der durch das init-Skript gestartet wurde, beendet. Als Workaround für diesen Fehler gehen Sie wie folgt vor: # Erstellen Sie einen Service-Datei-Wrapper mit demselben Namen wie das init-Skript und der Dateinamenerweiterung <tt>.service</tt>: <br/>[Unit]<br/>Description=''DESCRIPTION''<br/>After=network.target<br/>
| |
| [Service]<br/>User=''USER''<br/>Type=forking1<br/>PIDFile=''PATH TO PID FILE''[https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#co-service-wrapper-type 1]<br/>ExecStart=''PATH TO INIT SCRIPT'' start<br/>ExecStop=''PATH TO INIT SCRIPT'' stop<br/>ExecStopPost=/usr/bin/rm -f ''PATH TO PID FILE''[https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#co-service-wrapper-type 1]<br/>
| |
| [Install]<br/>WantedBy=multi-user.target2<br/>Ersetzen Sie alle Werte in ''GROSSBUCHSTABEN'' durch die entsprechenden Werte. | |
| | |
| {|class="wikitable sortable"
| |
|
| |
| |-
| |
| || [[#co-service-wrapper-type|1]]
| |
| || Optional; nur zu verwenden, wenn mit dem init-Skript ein Daemon gestartet wird.
| |
| |-
| |
| || [[#co-service-wrapper-target|2]]
| |
| || <tt>multi-user.target</tt> startet ebenfalls das init-Skript, wenn Sie in <tt>graphical.target</tt> booten. Falls der Start nur beim Booten in den Display-Manager erfolgen soll, verwenden Sie hier <tt>graphical.target</tt>.
| |
| |- | | |- |
| |} | | | Anwendung || [[Systemd/Anwendung]] |
| # Starten Sie den Daemon mit <tt>systemctl start ''ANWENDUNG''</tt>.
| |
| | |
| == Anpassen von systemd ==
| |
| ====== Warnung: Vermeiden der Überschreibung von Anpassungen ======
| |
| Passen Sie systemd stets in <tt>/etc/systemd/</tt> an, ''nicht'' in <tt>/usr/lib/systemd/</tt>. Ansonsten werden Ihre Änderungen bei der nächsten Aktualisierung von systemd überschrieben.
| |
| | |
| === Anpassen von Unit-Dateien ===
| |
| Die systemd-Unit-Dateien befinden sich in<tt>/usr/lib/systemd/system</tt>. Zum Anpassen fahren Sie wie folgt fort: # Kopieren Sie die zu bearbeitenden Dateien aus <tt>/usr/lib/systemd/system</tt> in <tt>/etc/systemd/system</tt>. Behalten Sie die ursprünglichen Dateinamen bei.
| |
| # Bearbeiten Sie die Kopien in <tt>/etc/systemd/system</tt>.
| |
| # Mit dem Kommando <tt>systemd-delta</tt> erhalten Sie einen Überblick über Ihre Konfigurationsänderungen. Hiermit werden Konfigurationsdateien verglichen und ermittelt, die andere Konfigurationsdateien überschreiben. Weitere Informationen finden Sie auf der man-Seite zu <tt>systemd-delta</tt>.
| |
| | |
| Die geänderten Dateien in <tt>/etc/systemd</tt> haben Vorrang vor den Originaldateien in <tt>/usr/lib/systemd/system</tt>, sofern die Dateinamen identisch sind.
| |
| | |
| ==== Konvertieren von xinetd-Diensten in systemd ====
| |
| Seit der Version SUSE Linux Enterprise Desktop 15 wurde die <tt>xinetd</tt>-Infrastruktur entfernt. In diesem Abschnitt wird beschrieben, wie Sie vorhandene benutzerdefinierte <tt>xinetd</tt>-Dienstdateien in <tt>systemd</tt>-Sockets konvertieren.
| |
| | |
| Für jede <tt>xinetd</tt>-Dienstdatei benötigen Sie mindestens zwei <tt>systemd</tt>-Unit-Dateien: die Socket-Datei (<tt> *.socket </tt>) und eine zugehörige Dienstdatei (<tt> *.service </tt>). Die Socket-Datei weist <tt>systemd</tt> an, welcher Socket erstellt werden soll, und die Dienstdatei weist <tt>systemd</tt> an, welche ausführbare Datei gestartet werden soll.
| |
| | |
| Betrachten Sie das folgende Beispiel für eine <tt>xinetd</tt>-Dienstdatei:
| |
| # '''cat /etc/xinetd.d/example'''
| |
| service example
| |
| {
| |
| socket_type = stream
| |
| protocol = tcp
| |
| port = 10085
| |
| wait = no
| |
| user = user
| |
| group = users
| |
| groups = yes
| |
| server = /usr/libexec/example/exampled
| |
| server_args = -auth=bsdtcp exampledump
| |
| disable = no
| |
| }
| |
| | |
| Zum Konvertieren in <tt>systemd</tt> benötigen Sie die folgenden beiden Dateien:
| |
| | |
| # '''cat /usr/lib/systemd/system/example.socket'''
| |
| [Socket]
| |
| ListenStream=0.0.0.0:10085
| |
| Accept=false
| |
| | |
| [Install]
| |
| WantedBy=sockets.target
| |
| root # cat /usr/lib/systemd/system/example.service
| |
| [Unit]
| |
| Description=example
| |
| | |
| [Service]
| |
| ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
| |
| User=user
| |
| Group=users
| |
| StandardInput=socket
| |
| | |
| Eine vollständige Liste der Socket- und Dienstdateioptionen für <tt>systemd</tt> finden Sie auf den man-Seiten zu systemd.socket und systemd.service (<tt>man 5 systemd.socket</tt>, <tt>man 5 systemd.service</tt>).
| |
| | |
| === Erstellen von „Drop-in-Dateien“ ===
| |
| Wenn eine Konfigurationsdatei nur um wenige Zeilen ergänzt oder nur ein kleiner Teil daraus geändert werden soll, können Sie sogenannte „Drop-in-Dateien“ verwenden. Mit den Drop-in-Dateien erweitern Sie die Konfiguration von Unit-Dateien, ohne die Unit-Dateien selbst bearbeiten oder überschreiben zu müssen.
| |
| | |
| Um beispielsweise einen einzigen Wert für den Dienst ''foobar'' in <tt>/usr/lib/systemd/system/ ''foobar.service''</tt> zu ändern, gehen Sie wie folgt vor: # Erstellen Sie ein Verzeichnis mit dem Namen <tt>/etc/systemd/system/''FOOBAR''.service.d/</tt>. <br/>Beachten Sie das Suffix <tt>.d</tt>. Ansonsten muss der Name des Verzeichnisses mit dem Namen des Dienstes übereinstimmen, der mit der Drop-in-Datei gepatcht werden soll.
| |
| # Erstellen Sie in diesem Verzeichnis eine Datei mit dem Namen <tt>''whatevermodification''.conf</tt>. <br/>Diese Datei darf nur eine Zeile mit dem zu ändernden Wert enthalten.
| |
| # Speichern Sie Ihre Änderungen in die Datei. Die Datei wird als Erweiterung der Originaldatei verwendet.
| |
| | |
| === Erstellen von benutzerdefinierten Zielen ===
| |
| Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, so dass die Administratoren eine eigene Runlevel-Konfiguration erstellen können. Mit systemd können Sie beliebig viele benutzerdefinierte Ziele erstellen. Zum Einstieg sollten Sie ein vorhandenes Ziel anpassen, beispielsweise <tt>graphical.target</tt>. # Kopieren Sie die Konfigurationsdatei <tt>/usr/lib/systemd/system/graphical.target</tt> in <tt>/etc/systemd/system/''MEIN_ZIEL''.target</tt> und passen Sie sie nach Bedarf an.
| |
| # Die im vorangegangenen Schritt kopierte Konfigurationsdatei enthält bereits die erforderlichen („harten“) Abhängigkeiten für das Ziel. Um auch die erwünschten („weichen“) Abhängigkeiten abzudecken, erstellen Sie ein Verzeichnis mit dem Namen <tt>/etc/systemd/system/''MEIN_ZIEL''.target.wants</tt>.
| |
| # Legen Sie für jeden erwünschten Dienst einen symbolischen Link von <tt>/usr/lib/systemd/system</tt> in <tt>/etc/systemd/system/''MEIN_ZIEL''.target.wants</tt> an.
| |
| # Sobald Sie alle Einstellungen für das Ziel festgelegt haben, laden Sie die systemd-Konfiguration neu. Damit wird das neue Ziel verfügbar: <br/> # '''systemctl daemon-reload'''
| |
| | |
| == Erweiterte Nutzung ==
| |
| In den nachfolgenden Abschnitten finden Sie weiterführende Themen für Systemadministratoren. Eine noch eingehendere Dokumentation finden Sie in der Serie von Lennart Pöttering zu systemd für Administratoren unter [http://0pointer.de/blog/projects http://0pointer.de/blog/projects].
| |
| | |
| === Bereinigen von temporären Verzeichnissen ===
| |
| <tt>systemd</tt> unterstützt das regelmäßige Bereinigen der temporären Verzeichnisse. Die Konfiguration aus der bisherigen Systemversion wird automatisch migriert und ist aktiv. <tt>tmpfiles.d</tt> (verwaltet temporäre Dateien) liest die Konfiguration aus den Dateien <tt>/etc/tmpfiles.d/*.conf</tt>, <tt>/run/tmpfiles.d/*.conf</tt> und <tt>/usr/lib/tmpfiles.d/*.conf</tt> aus. Die Konfiguration in <tt>/etc/tmpfiles.d/*.conf</tt> hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In <tt>/usr/lib/tmpfiles.d/*.conf</tt> speichern die Pakete die Konfigurationsdateien.)
| |
| | |
| Im Konfigurationsformat ist eine Zeile pro Pfad vorgeschrieben, wobei diese Zeile die Aktion und den Pfad enthalten muss und optional Felder für Modus, Eigentümer, Alter und Argument (je nach Aktion) enthalten kann. Im folgenden Beispiel wird die Verknüpfung der X11-Sperrdateien aufgehoben:
| |
| | |
| Type Path Mode UID GID Age Argument
| |
| r /tmp/.X[0-9]*-lock
| |
| | |
| So rufen Sie den Status aus dem tmpfile-Zeitgeber ab:
| |
| | |
| # '''systemctl status systemd-tmpfiles-clean.timer'''
| |
| systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
| |
| Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
| |
| Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
| |
| Docs: man:tmpfiles.d(5)
| |
| man:systemd-tmpfiles(8)
| |
| | |
| Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
| |
| Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.
| |
| | |
| Weitere Informationen zum Arbeiten mit temporären Dateien finden Sie unter <tt>man 5 tmpfiles.d</tt>.
| |
| | |
| === Systemprotokoll ===
| |
| In [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-basics-services-debugging Abschnitt 13.6.8, „Fehlersuche für Dienste“] wird erläutert, wie Sie Protokollmeldungen für einen bestimmten Dienst anzeigen. Die Anzeige von Protokollmeldungen ist allerdings nicht auf Dienstprotokolle beschränkt. Sie können auch auf das gesamte von <tt>systemd</tt> geschriebene Protokoll (das sogenannte „Journal“) zugreifen und Abfragen darauf ausführen. Mit dem Befehl <tt>journalctl</tt> zeigen Sie das gesamte Protokoll an, beginnend mit den ältesten Einträgen. Informationen zu weiteren Optionen, beispielsweise zum Anwenden von Filtern oder zum Ändern des Ausgabeformats, finden Sie unter <tt>man 1 journalctl</tt>.
| |
| | |
| === Aufnahmen ===
| |
| Mit dem Subkommando <tt>isolate</tt> können Sie den aktuellen Status von <tt>systemd</tt> als benannten Snapshot speichern und später wiederherstellen. Dies ist beim Testen von Diensten oder benutzerdefinierten Zielen hilfreich, weil Sie jederzeit zu einem definierten Status zurückkehren können. Ein Snapshot ist nur in der aktuellen Sitzung verfügbar; beim Neubooten wird er automatisch gelöscht. Der Snapshot-Name muss auf <tt>.snapshot</tt> enden.
| |
| | |
| Erstellen eines Snapshots
| |
| | |
| # '''systemctl snapshot ''MY_SNAPSHOT''.snapshot'''
| |
| | |
| Löschen eines Snapshots
| |
| | |
| # '''systemctl delete ''MY_SNAPSHOT''.snapshot'''
| |
| | |
| Anzeigen eines Snapshots
| |
| | |
| # '''systemctl show ''MY_SNAPSHOT''.snapshot'''
| |
| | |
| Aktivieren eines Snapshots
| |
| | |
| # '''systemctl isolate ''MY_SNAPSHOT''.snapshot'''
| |
| | |
| === Laden der Kernelmodule ===
| |
| Mit <tt>systemd</tt> können Kernel-Module automatisch zum Bootzeitpunkt geladen werden, und zwar über die Konfigurationsdatei in <tt>/etc/modules-load.d</tt>. Die Datei sollte den Namen ''MODUL''.conf haben und den folgenden Inhalt aufweisen:
| |
| | |
| # load module ''MODULE'' at boot time
| |
| ''MODULE''
| |
| | |
| Falls ein Paket eine Konfigurationsdatei zum Laden eines Kernel-Moduls installiert, wird diese Datei unter <tt>/usr/lib/modules-load.d</tt> installiert. Wenn zwei Konfigurationsdateien mit demselben Namen vorhanden sind, hat die Datei unter <tt>/etc/modules-load.d</tt> Vorrang.
| |
| | |
| Weitere Informationen finden Sie auf der man-Seite <tt>modules-load.d(5)</tt>.
| |
| | |
| === Ausführen von Aktionen vor dem Laden eines Dienstes ===
| |
| Bei System V mussten init-Aktionen, die vor dem Laden eines Diensts ausgeführt werden müssen, in <tt>/etc/init.d/before.local</tt> festgelegt werden. Dieses Verfahren wird in systemd nicht mehr unterstützt. Wenn Aktionen vor dem Starten von Diensten ausgeführt werden müssen, gehen Sie wie folgt vor:
| |
| | |
| Laden der Kernelmodule
| |
| | |
| Erstellen Sie eine Drop-in-Datei im Verzeichnis <tt>/etc/modules-load.d</tt> (Syntax siehe <tt>man modules-load.d</tt>).
| |
| | |
| Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers
| |
| | |
| Erstellen Sie eine Drop-in-Datei in <tt>/etc/tmpfiles.d</tt> (Syntax siehe <tt>man tmpfiles.d</tt>).
| |
| | |
| Weitere Aufgaben
| |
| | |
| Erstellen Sie eine Systemdienstdatei (beispielsweise <tt>/etc/systemd/system/before.service</tt>) anhand der folgenden Schablone:
| |
| | |
| [Unit]
| |
| Before=''NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE''
| |
| [Service]
| |
| Type=oneshot
| |
| RemainAfterExit=true
| |
| ExecStart=''YOUR_COMMAND''
| |
| # beware, executable is run directly, not through a shell, check the man pages
| |
| # systemd.service and systemd.unit for full syntax
| |
| [Install]
| |
| # target in which to start the service
| |
| WantedBy=multi-user.target
| |
| #WantedBy=graphical.target
| |
| | |
| Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Kommandos aus (als <tt>root</tt>):
| |
| | |
| # '''systemctl daemon-reload'''
| |
| # '''systemctl enable before'''
| |
| | |
| Bei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen:
| |
| | |
| # '''systemctl daemon-reload'''
| |
| | |
| === Kernel-Steuergruppen (cgroups) ===
| |
| Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde. Einige Dienste (z. B. Apache) erzeugen zahlreiche externe Prozesse (z. B. CGI- oder Java-Prozesse), die wiederum weitere Prozesse erzeugen. Eindeutige Zuweisungen sind damit schwierig oder völlig unmöglich. Wenn ein Dienst nicht ordnungsgemäß beendet wird, bleiben zudem ggf. einige untergeordnete Dienste weiterhin aktiv.
| |
| | |
| Bei systemd wird jeder Dienst in eine eigene cgroup aufgenommen, womit dieses Problem gelöst ist. cgroups sind eine Kernel-Funktion, mit der die Prozesse mit allen ihren untergeordneten Prozessen in hierarchisch strukturierten Gruppen zusammengefasst werden. Die cgroups werden dabei nach dem jeweiligen Dienst benannt. Da ein nicht privilegierter Dienst seine cgroup nicht „verlassen“ darf, ist es damit möglich, alle von einem Dienst erzeugten Prozesse mit dem Namen dieses Dienstes zu versehen.
| |
| | |
| Mit dem Kommando <tt>systemd-cgls</tt> erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:
| |
| | |
| ====== Auflisten aller Prozesse, die zu einem Dienst gehören [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#id-1.3.4.5.10.8.5 #] ======
| |
| root # systemd-cgls --no-pager
| |
| ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
| |
| ├─user.slice
| |
| │ └─user-1000.slice
| |
| │ ├─session-102.scope
| |
| │ │ ├─12426 gdm-session-worker [pam/gdm-password]
| |
| │ │ ├─15831 gdm-session-worker [pam/gdm-password]
| |
| │ │ ├─15839 gdm-session-worker [pam/gdm-password]
| |
| │ │ ├─15858 /usr/lib/gnome-terminal-server
| |
| | |
| [...]
| |
| | |
| └─system.slice
| |
| ├─systemd-hostnamed.service
| |
| │ └─17616 /usr/lib/systemd/systemd-hostnamed
| |
| ├─cron.service
| |
| │ └─1689 /usr/sbin/cron -n
| |
| ├─postfix.service
| |
| │ ├─ 1676 /usr/lib/postfix/master -w
| |
| │ ├─ 1679 qmgr -l -t fifo -u
| |
| │ └─15590 pickup -l -t fifo -u
| |
| ├─sshd.service
| |
| │ └─1436 /usr/sbin/sshd -D
| |
| | |
| [...]
| |
| | |
| Weitere Informationen zu cpgroups finden Sie in [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-tuning-cgroups.html Chapter 9, ][https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-tuning-cgroups.html Kernel Control Groups].
| |
| | |
| === Beenden von Diensten (Senden von Signalen) ===
| |
| Wie in [https://documentation.suse.com/de-de/sled/15-SP1/html/SLED-all/cha-systemd.html#sec-boot-systemd-advanced-cgroups Abschnitt 13.6.6, „Kernel-Steuergruppen (cgroups)“] erläutert, kann ein Prozess in einem System-V-init-System nicht immer eindeutig seinem übergeordneten Dienstprozess zugeordnet werden. Das erschwert das Beenden eines Dienstes und seiner untergeordneten Dienste. Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als "Zombie-Prozess" zurück.
| |
| | |
| Durch das Konzept von systemd, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Dienstes eindeutig erkannt werden, so dass Sie ein Signal zu diesen Prozessen senden können. Mit Use <tt>systemctl kill</tt> senden Sie die Signale an die Dienste. Eine Liste der verfügbaren Signale finden Sie in <tt>man 7 signals</tt>.
| |
| | |
| Senden von <tt>SIGTERM</tt> an einen Dienst
| |
| | |
| <tt>SIGTERM</tt> ist das standardmäßig gesendete Signal.
| |
| | |
| # '''systemctl kill ''MY_SERVICE'''''
| |
| | |
| Senden von ''SIGNAL'' an einen Dienst
| |
| | |
| Mit der Option <tt>-s</tt> legen Sie das zu sendende Signal fest.
| |
| | |
| # '''systemctl kill -s ''SIGNAL'' ''MY_SERVICE'''''
| |
| | |
| '''Auswählen von Prozessen'''
| |
| | |
| Standardmäßig sendet das Kommando <tt>kill</tt> das Signal an <tt>alle</tt> Prozesse der angegebenen cgroup. Sie können dies jedoch auf den Prozess <tt>control</tt> oder <tt>main</tt> beschränken. Damit können Sie beispielsweise das Neuladen der Konfiguration eines Dienstes mit dem Signal <tt>SIGHUP</tt> erzwingen:
| |
| | |
| # '''systemctl kill -s SIGHUP --kill-who=main ''MY_SERVICE'''''
| |
| | |
| ====== Warnung: Beenden oder Neustarten des D-BUS-Dienstes wird nicht unterstützt ======
| |
| Der D-Bus-Dienst fungiert als Meldungsbus für die Kommunikation zwischen den systemd-Clients und dem systemd-Manager, der als PID 1 ausgeführt wird. <tt>dbus</tt> ist zwar ein eigenständiger Daemon, bildet jedoch auch einen wesentlichen Bestandteil der Initialisierungsinfrastruktur.
| |
| | |
| Das Beenden von <tt>dbus</tt> oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu beenden oder neu zu starten. Hiermit wird die systemd-Client/Server-Kommunikation unterbrochen, sodass die meisten systemd-Funktionen unbrauchbar werden.
| |
| | |
| Das Beenden oder Neustarten von <tt>dbus</tt> wird daher weder empfohlen noch unterstützt.
| |
| | |
| === Fehlersuche für Dienste ===
| |
| Standardmäßig ist die Ausgabe von systemd auf ein Minimum beschränkt. Wenn ein Dienst ordnungsgemäß gestartet wurde, erfolgt keine Ausgabe. Bei einem Fehler wird eine kurze Fehlermeldung angezeigt. Mit <tt>systemctl status</tt> können Sie jedoch die Fehlersuche für den Start und die Ausführung eines Dienstes vornehmen.
| |
| | |
| systemd umfasst einen Protokollierungsmechanismus („Journal“), mit dem die Systemmeldungen protokolliert werden. Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen. Das Kommando <tt>status</tt> hat eine ähnliche Funktion wie <tt>tail</tt> und kann zudem die Protokollmeldungen in verschiedenen Formaten anzeigen, ist also ein wirksames Hilfsmittel für die Fehlersuche.
| |
| | |
| Anzeigen von Fehlern beim Starten von Diensten
| |
| | |
| Wenn ein Dienst nicht gestartet wird, erhalten Sie mit <tt>systemctl status ''MEIN_DIENST''</tt> eine ausführliche Fehlermeldung:
| |
| | |
| root # systemctl start apache2
| |
| Job failed. See system journal and 'systemctl status' for details.
| |
| root # systemctl status apache2
| |
| Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
| |
| Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago
| |
| Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE)
| |
| CGroup: name=systemd:/system/apache2.service
| |
| | |
| Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line
| |
| 205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>
| |
| | |
| Anzeigen der letzten ''n'' Dienstmeldungen
| |
| | |
| Standardmäßig zeigt das Subkommando <tt>status</tt> die letzten zehn Meldungen an, die ein Dienst ausgegeben hat. Mit dem Parameter <tt>--lines=''n''</tt> legen Sie eine andere Anzahl fest:
| |
| | |
| # '''systemctl status chronyd'''
| |
| # '''systemctl --lines=20 status chronyd'''
| |
| | |
| Anzeigen von Dienstmeldungen im Anhängemodus
| |
| | |
| Mit der Option „--follow“ erhalten Sie einen <tt>Live-Stream</tt> mit Dienstmeldungen; diese Option entspricht <tt>tail -f</tt>:
| |
| # '''systemctl --follow status chronyd'''
| |
| | |
| Ausgabeformat der Meldungen
| |
| | |
| Mit dem Parameter <tt>--output=''mode''</tt> legen Sie das Ausgabeformat für die Dienstmeldungen fest. Die wichtigsten Modi sind:
| |
| | |
| <tt>short</tt>
| |
| | |
| Das Standardformat. Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an.
| |
| | |
| <tt>verbose</tt>
| |
| | |
| Vollständige Ausgabe mit sämtlichen Feldern.
| |
| | |
| <tt>cat</tt>
| |
| | |
| Kurze Ausgabe ohne Zeitstempel.
| |
| | |
| == Systemd ==
| |
| * Bei einer Reihe von Distributionen kümmert sich mittlerweile nicht mehr Sysvinit, sondern Systemd um den Systemstart.
| |
| * Das erst zwei Jahre alte Init-System verspricht den Bootprozess zu beschleunigen und erfordert keine explizite Konfiguration der Abhängigkeiten zwischen Systemdiensten; nebenbei schafft es einige distributionsspezifische Eigenarten aus der Welt.
| |
| * Bei Linux-Distributionen übergibt der Kernel traditionell '''Sysvinit '''die Verantwortung zur Einrichtung des Systems. Einige Jahre sah alles danach aus, als würde '''Upstart '''das angestaubte, aber noch weitverbreitete Init-System beerben, doch mittlerweile immer mehr Distributionen auf '''Systemd '''um – '''abgesehen von Ubuntu ''', das laut Mark Suttleworth auf absehbare Zeit bei Upstart bleiben wird.
| |
| * Fedora nutzt Systemd seit Version 15, auch in OpenSuse und Mandriva 2011 kommt das neue Init-System zum Einsatz; Mageia steigt mit Version 2 um. Bei Arch Linux und Gentoo sowie Debian Testing liegt Systemd bei; bei einigen weitere Distributionen wird der optionale Einsatz oder der Umstieg diskutiert.
| |
| * Eine der Besonderheiten von Systemd ist der parallele Start von Hintergrunddiensten, ohne dass Abhängigkeiten zwischen diesen explizit festgelegt werden müssen; das nutzt Hardware-Ressourcen effizienter und lässt das System flott starten.
| |
| * Systemd erledigt zudem einige Aufgaben, um die sich bislang meist distributionsspezifische Skripte kümmern; ganz nebenbei beseitigt es damit einige Unterschiede bei der Bedienung und Konfiguration von Distributionen.
| |
| | |
| = systemd =
| |
| {|class="wikitable sortable"
| |
| 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'''
| |
| || 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" | [http://freedesktop.org/wiki/Software/systemd freedesktop.org/wiki/Software/systemd]
| |
| |- | | |- |
| | | 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 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 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 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 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]] |
|
| |
|
| == Weitere Informationen ==
| | </noinclude> |
| # Startseite: [http://www.freedesktop.org/wiki/Software/systemd http://www.freedesktop.org/wiki/Software/systemd]
| |
| # systemd für Administratoren: Lennart Pöttering, einer der systemd-Autoren, hat eine Serie von Blogeinträgen verfasst. (Zum Zeitpunkt, als dieses Kapitel verfasst wurde, standen bereits 13 Einträge zur Verfügung.) Diese sind unter [http://0pointer.de/blog/projects http://0pointer.de/blog/projects] zu finden.
| |
|
| |
| [[Category:Linux:Dienstverwaltung]]
| |
| [[Kategorie:Linux:Systemstart]]
| |
| [[Kategorie:Linux:Systemd]]
| |