Provided by: manpages-de_2.5-1_all 
BEZEICHNUNG
systemd.kill - Konfiguration für das Verfahren zum Töten von Prozessen
ÜBERSICHT
service.service, socket.socket, mount.mount, swap.swap, scope.scope
BESCHREIBUNG
Unit-Konfigurationsdateien für Dienste, Sockets, Einhängepunkte, Auslagerungsgeräte und Geltungsbereiche
nutzen einen Untermenge der Konfigurationsoptionen gemeinsam, die das Verfahren zum Töten von Prozessen,
die zu der Unit gehören, definieren.
Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen fünf Unit-Typen gemeinsam
benutzt werden. Siehe systemd.unit(5) für die Konfiguration der von allen Unit-Typen gemeinsam benutzten
Optionen und systemd.service(5), systemd.socket(5), systemd.swap(5), systemd.mount(5) und
systemd.scope(5) für weitere Informationen über die Konfigurationsdateioptionen, die für jeden Unit-Typen
spezifisch sind.
Die Konfigurationsoptionen für das Verfahren zum Töten werden in den Abschnitten [Service], [Socket],
[Mount] oder [Swap], abhängig vom Unit-Typ, konfiguriert.
OPTIONEN
KillMode=
Legt fest, wie die Prozesse dieser Unit getötet werden sollen. Entweder control-group, process, mixed
oder none.
Falls auf control-group gesetzt, werden alle verbleibenden Prozesse in der Control-Gruppe dieser Unit
beim Unit-Stop getötet (für Dienste: nachdem der Stopp-Befehl ausgeführt wurde, wie in ExecStop=
konfiguriert). Falls auf process gesetzt, wird nur der Hauptprozess selbst getötet. Falls auf mixed
gesetzt, wird das Signal SIGTERM (siehe unten) an den Hauptprozess gesandt, während nachfolgende
Signale SIGKILL (siehe unten) an alle verbliebenen Prozesse der Control-Gruppe dieser Unit gesandt
werden. Falls auf none gesetzt wird kein Prozess getötet. In diesem Fall wird nur der Befehl Stop
beim Unit-Stopp ausgeführt, aber weiter kein Prozess getötet. Prozesse ,die nach dem Stop noch am
Leben sind, verbleiben in dieser Control-Gruppe und die Control-Gruppe existiert nach dem Stopp
weiterhin, außer sie ist leer.
Prozesse werden zuerst mittels SIGTERM beendet (falls das zu sendende Signal nicht mittels
KillSignal= geändert wurde). Falls dann nach einer Verzögerung (konfiguriert über die Option
TimeoutStopSec=) immer noch Prozesse verbleiben, wird die Beendigungsaufforderung mit dem Signal
SIGKILL wiederholt (außer dies ist mit der Option SendSIGKILL= deaktiviert). Siehe kill(2) für
weitere Informationen.
Standardmäßig control-group.
KillSignal=
Legt fest, welches Signal zum Töten eines Dienstes verwandt werden soll. Dies steuert, welches Signal
im ersten Schritt beim Herunterfahren einer Unit (siehe oben) gesandt werden soll, darauf folgt
normalerweise ein SIGKILL (siehe oben und unten). Für eine Liste der gültigen Signale siehe
signal(7). Standardmäßig SIGTERM.
Beachten Sie, dass direkt nach dem Senden des in dieser Einstellung festgelegten Signals Systemd
immer SIGCONT senden wird, um sicherzustellen, dass selbst suspendierte Prozesse sauber beendet
werden können.
SendSIGHUP=
Legt fest, ob SIGHUP sofort nach dem Senden des mittels KillSignal= konfigurierten Signals gesandt
werden soll. Dies ist nützlich, um Shells und Shell-ähnlichen Programmen anzuzeigen, dass ihre
Verbindung abgetrennt wurde. Akzeptiert einen logischen Wert. Standardmäßig »no«.
SendSIGKILL=
Legt fest, ob an verbliebene Prozesse nach einer Zeitüberschreitung SIGKILL gesandt werden soll,
falls nach dem normalen Herunterfahrprozess noch Dienste verblieben sind. Akzeptiert einen logischen
Wert. Standardmäßig »yes«.
SIEHE AUCH
systemd(1), systemctl(1), journalctl(8), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.swap(5), systemd.mount(5), systemd.exec(5), systemd.directives(7), kill(2), signal(7)
Ü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 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 <debian-l10n-german@lists.debian.org>.