plucky (5) systemd.scope.5.gz

Provided by: manpages-de_4.25.1-1_all bug

BEZEICHNUNG

       systemd.scope - Bereichs-Unit-Konfiguration

ÜBERSICHT

       Bereich.scope

BESCHREIBUNG

       Bereichs-Units werden nicht über Unit-Konfigurationsdateien konfiguriert, sondern werden nur
       programmatisch mittels der Bus-Schnittstellen von Systemd erstellt. Sie sind ähnlich zu Dateinamen
       benannt. Eine Unit, deren Namen auf »&.scope« endet, bezieht sich auf eine Bereichs-Unit. Bereichs-Units
       verwalten eine Gruppe von Systemprozessen. Anders als Dienste-Units verwalten Bereichs-Units extern
       erstellte Prozesse und erstellen selbst keine Prozesse mittels »fork«.

       Der Hauptzweck von Bereichs-Units ist die Gruppierung von Arbeitsprozessen eines Systemdienstes für die
       Organisation und die Verwaltung von Ressourcen.

       systemd-run --scope kann zum leichten Starten eines Befehls in einer neuen Bereichs-Unit von der
       Befehlszeile aus verwandt werden.

       Siehe die Neue Control-Gruppen-Schnittstelle[1] für eine Einführung, wie für Programme Bereichs-Units
       eingesetzt werden können.

       Beachten Sie, dass Bereichs-Units, anders als Dienste-Units, keinen »Hauptprozess« haben, alle Prozesse
       im Bereich sind äquivalent. Der Lebenszyklus der Bereichs-Unit ist nicht an die Lebensdauer eines
       bestimmten Prozesses gebunden, sondern an die Existenz von mindestestens einem Prozess im Bereich. Das
       bedeutet auch, dass der Exit-Status eines Prozesses nicht relevant für den Fehlerzustand der
       Bereichs-Unit ist. Bereichs-Units können weiterhin einen Fehlerzustand einnehmen, beispielsweise aufgrund
       von Ressourcenerschöpfung und dem Erreichen von Zeitüberschreitungen, aber nicht aufgrund unsauberer
       Beendigungen von Programmen innerhalb der Unit. Da die Prozesse, die als Bereichs-Unit verwaltet werden,
       im Allgemeinen Kindprozess des ursprünglichen Prozesses, der sie per Fork gestartet hat, bleiben, ist es
       auch die Aufgabe dieses Prozesses, ihre Exit-Status einzusammeln und entsprechend zu reagieren.

AUTOMATISCHE ABHÄNGIGKEITEN

   Implizite Abhängigkeiten
       Wie in systemd.resource-control(5) dokumentiert, können implizite Abhängigkeiten als Ergebnis von
       Ressourcensteuerungsparametern hinzugefügt werden.

   Standardabhängigkeiten
       Die folgenden Abhängigkeiten werden hinzugefügt, es sei denn, DefaultDependencies=no ist gesetzt:

       •   Bereichs-Units erhalten automatisch Abhängigkeiten vom Typ Conflicts= und Before= von
           shutdown.target. Dies stellt sicher, dass Bereichs-Units vor dem Herunterfahren entfernt werden. Nur
           Bereichs-Units, die in der frühen Systemstartphase oder im späten Herunterfahren involviert sind,
           sollten die Option DefaultDependencies= deaktivieren.

OPTIONEN

       Bereichs-Dateien können einen Abschnit [Unit] enthalten, der in systemd.unit(5) beschrieben ist.

       Bereichs-Units können einen Abschnitt »[Scope]« enthalten, der Informationen über den Bereich und die
       darin enthaltenen Units weitergibt. Eine Reihe von Optionen, die in diesem Abschnitt verwandt werden,
       werden auch von anderen Unit-Typen verwendet. Diese Optionen sind in systemd.kill(5) und
       systemd.resource-control(5) dokumentiert. Folgende Optionen sind spezifisch für den Abschnitt »[Scope]«
       von Bereichs-Units:

       OOMPolicy=
           Konfiguriert die Richtlinie für die Speichererschöpfungs- (OOM-)Beendigung für den Kernel und den
           OOM-Klller im Anwendungsraum systemd-oomd.service(8). Wenn unter Linux der Speicher so knapp wird,
           dass der Kernel Schwierigkeiten bekommt, Speicher für sich selbst zu reservieren, dann kann er sich
           entscheiden, laufende Prozesse zu beenden, um Speicher freizugeben und den Speicherdruck zu
           reduzieren. Beachten Sie, dass systemd-oomd.service(8) eine flexiblere Lösung ist, die zu verhindern
           versucht, dass Speichererschöpfungssituationen im Anwendungsraum auftreten, nicht nur im Kernel,
           indem versucht wird, Dienste früher zu beenden, bevor der Kernel agieren müsste.

           Diese Einstellung akzeptiert entweder continue, stop oder kill. Falls auf continue gesetzt und ein
           Prozess in der Unit vom OOM-Killer beendet wird, wird dies protokolliert aber die Unit läuft weiter.
           Falls auf stop gesetzt, wird das Ereignis protokolliert, aber die Unit wird sauber durch den
           Diensteverwalter beendet. Falls auf kill gesetzt und einer der Prozesse der Unit wird durch den
           OOM-Killer beendet, wird der Kernel angewiesen, auch alle verbleibenden Prozesse der Unit durch
           Setzen des Attributes memory.oom.group auf 1 durch den OOM-Killer zu beenden; siehe auch die
           Kernelseite Control-Gruppe v2[2].

           Standardmäßig der Wert, auf den die Einstellung DefaultOOMPolicy= in systemd-system.conf(5) gesetzt
           ist, außer bei Units, bei denen Delegate= eingeschaltet ist, wo die Vorgabe continue ist.

           Verwenden Sie die Einstellung OOMScoreAdjust=, um zu konfigurieren, ob Prozesse der Unit als
           bevorzugte oder weniger bevorzugte Kandidaten für Prozessbeendigungen durch die Logik des OOM-Killers
           von Linux betrachtet werden sollen. Siehe systemd.exec(5) für Details.

           Diese Einstellung gilt auch für systemd-oomd.service(8). Ähnlich wie beim vom Kernel durchgeführten
           Kernel-OOM-Tötungen bestimmt diese Einstellung den Zustand der Unit, nachdem systemd-oomd(8) eine ihr
           zugeordnete Cgroup beendet hat.

           Hinzugefügt in Version 253.

       RuntimeMaxSec=
           Konfiguriert eine maximale Laufzeit für den Bereich. Falls dies verwandt wird und die Unit länger als
           die festgelegte Zeit aktiv war, wird sie beendet und in einen Fehlerzustand gebracht. Übergeben Sie
           »infinity« (die Vorgabe), um keine Laufzeitbegrenzung zu konfigurieren.

           Hinzugefügt in Version 244.

       RuntimeRandomizedExtraSec=
           Diese Option verändert RuntimeMaxSec= durch Erhöhung der maximalen Laufzeit mit einer
           gleichverteilten Dauer zwischen 0 und dem festgelegten Wert (in Sekunden). Falls RuntimeMaxSec= nicht
           festgelegt ist, wird diese Funktionalität deaktiviert.

           Hinzugefügt in Version 250.

       Lesen Sie systemd.unit(5), systemd.exec(5) und systemd.kill(5) für weitere Einstellungen.

SIEHE AUCH

       systemd(1), systemd-run(1), systemd.unit(5), systemd.resource-control(5), systemd.service(5),
       systemd.directives(7).

ANMERKUNGEN

        1. Neue Control-Gruppen-Schnittstellen
           https://systemd.io/CONTROL_GROUP_INTERFACE

        2. Control-Gruppe v2
           https://docs.kernel.org/admin-guide/cgroup-v2.html

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE
       HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
       Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.