Provided by: manpages-de_2.15-1build1_all bug

BEZEICHNUNG

       systemd.socket - Socket-Unit-Konfiguration

ÜBERSICHT

       Socket.socket

BESCHREIBUNG

       Eine Unit-Konfigurationsdatei, deren Namen in ».socket« endet, kodiert Informationen über
       einen IPC oder Netzwerk-Socket oder ein Dateisystem-FIFO, der von Systemd gesteuert und
       überwacht wird, für Socket-basierte Aktivierung.

       Diese Handbuchseite führt die für diesen Unit-Typ spezifischen Konfigurationsoptionen auf.
       Siehe systemd.unit(5) für die gemeinsamen Optionen aller Unit-Konfigurationsdateien. Die
       gemeinsamen Konfigurationseinträge werden in den generischen Abschnitten [Unit] und
       [Install] konfiguriert. Die Socket-spezifischen Konfigurationsoptionen werden in dem
       Abschnitt [Socket] konfiguriert.

       Zusätzliche Optionen sind in systemd.exec(5), das die Ausführungsumgebung, in der die
       Befehle ExecStartPre=, ExecStartPost=, ExecStopPre= und ExecStopPost= ausgeführt werden
       und in systemd.kill(5), das die Art der Beendigung der Prozesse definiert und in
       systemd.resource-control(5), das die Ressourcensteuerungseinstellungen für die Prozesse
       des Sockets konfiguriert, aufgeführt.

       Für jede Socket-Datei muss eine passende Dienstedatei existieren, die den bei eingehendem
       Verkehr auf dem Socket zu startenden Dienst beschreibt (siehe systemd.service(5) für
       weitere Informationen über .service-Dateien). Der Name der .service-Unit ist standardmäßig
       der gleiche wie der Name der .socket-Unit, dies kann aber mit der weiter unten
       beschriebenen Option Service= verändert werden. Abhängig von den Einstellungen der unten
       beschriebenen Option Accept= muss diese Dienste-Unit entweder wie die .socket-Unit (aber
       mit ersetzter Endung) benannt sein, außer dies wird mit Service= außer Kraft gesetzt, oder
       sie muss eine Vorlagen-Unit sein, die auf die gleiche Art benannt ist. Beispiel: Eine
       Socket-Datei foo.socket benötigt einen passenden Dienst foo.service, falls Accept=no
       gesetzt ist. Falls Accept=yes gesetzt ist, muss eine Dienstevorlagedatei foo@.service
       existieren, aus der die Dienste für jede eingehende Verbindung instanziiert werden.

       Es wird keine implizite Abhängigkeit WantedBy= oder RequiredBy= vom Socket auf den Dienst
       hinzugefügt. Dies bedeutet, dass der Dienst ohne den Socket gestartet werden darf. In
       diesem Fall muss er in der Lage sein, den Socket selbst zu öffnen. Um dies zu verhindern,
       kann eine explizite Abhängigkeit Requires= hinzugefügt werden.

       Socket-Units können zur Implementierung des bedarfsorientierten Startens von Diensten
       sowie zum parallelen Starten von Diensten verwandt werden. Siehe die am Ende der
       Einleitung verlinkten Blog-Einträgen.

       Beachten Sie, dass Daemon-Software, die für Socket-Aktivierung mit Socket-Units
       konfiguriert ist, in der Lage sein muss, Sockets von Systemd zu akzeptieren, entwender
       mittels Systemds nativer Socket-Übergabeschnittstelle (siehe sd_listen_fds(3) für Details)
       oder mittels traditioneller inetd(8)-artiger Socket-Übergabe (d.h. Sockets, die über
       Standardein- und -ausgabe mittels StandardInput=socket in der Dienstedatei übergeben
       werden).

       Alle mittels .socket-Units bereitgestellten Netzwerk-Sockets werden im Netzwerknamensraum
       des Rechners bereitgestellt (siehe network_namespaces(7)). Dies bedeutet allerdings nicht,
       dass der Dienst, der durch eine konfigurierte Socket-Unit aktiviert wird, auch Teil des
       Netzwerk-Namensraum des Rechners sein muss. Der Betrieb von Diensten in ihrem eigenen
       Netzwerknamensraum (beispielsweise mittels PrivateNetwork=, siehe systemd.exec(5)) wird
       unterstützt und ist sogar gängige Praxis. Dabei werden nur die mittels Socket-Aktivierung
       konfigurierten Sockets vom Namensraum des Rechners empfangen. Bei einer solchen
       Installation ist die Kommunikation mit dem Netzwerknamensraum des Rechners durch die
       hereingereichten Aktivierungs-Sockets erlaubt, während alle Sockets, die vom Dienste-Code
       selbst bereitgestellt werden, dem Namensraum des Dienstes selbst zugeordnet sind und daher
       möglicherweise einer deutlich restriktiveren Konfiguration unterliegen könnten.

AUTOMATISCHE ABHÄNGIGKEITEN

   Implizite Abhängigkeiten
       Die folgenden Abhängigkeiten werden implizit hinzugefügt:

       ·   Socket-Units erhalten automatisch eine Abhängigkeit Before= auf die von ihnen
           aktivierten Dienste-Units.

       ·   Socket-Units, die sich auf Dateisystempfade beziehen (wie AF_UNIX-Sockets oder FIFOs)
           erhalten implizit eine Abhängigkeit Requires= und After= auf alle für den Zugriff auf
           diese Pfade notwendigen Einhänge-Units.

       ·   Socket-Units, die die Einstellung BindToDevice= verwenden, erhalten automatisch
           Abhängigkeiten BindsTo= und After= von der Geräte-Unit, die die festgelegte
           Netzwerkschnittstelle kapselt.

       Zusätzliche implizite Abhängigkeiten als Ergebnis der Ausführung und der gemäß
       systemd.exec(5) und systemd.resource-control(5) dokumentierten
       Ressourcen-Steuerungsparameter können hinzugefügt werden.

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

       ·   Socket-Units erhalten automatisch eine Abhängigkeit Before= von sockets.target.

       ·   Socket-Units erhalten automatisch ein Abhängigkeitspaar After= und Requires= von
           sysinit.target und ein Abhängigkeitspaar Before= und Conflicts= von shutdown.target.
           Diese Abhängigkeiten stellen sicher, dass die Socket-Unit vor den normalen Diensten
           beim Systemstart gestartet und beim Herunterfahren beendet wird. Nur Sockets, die in
           der frühen Systemstartphase oder spät beim Herunterfahren beteiligt sind, sollten die
           Option DefaultDependencies= deaktivieren.

OPTIONEN

       Socket-Dateien müssen einen Abschnitt »[Socket]« enthalten, der Informationen über das
       überwachte Socket oder den überwachten FIFO weitergibt. Eine Reihe von Optionen, die in
       diesem Abschnitt angegeben werden können, werden auch von anderen Unit-Typen verwandt.
       Diese Optionen sind in systemd.exec(5) und systemd.kill(5) dokumentiert. Die für den
       Abschnitt »[Socket]« in Socket-Units speziellen Optionen sind die folgenden:

       ListenStream=, ListenDatagram=, ListenSequentialPacket=
           Legt eine Adresse fest, an der auf Anfragen für einen Stream- (SOCK_STREAM), Datagram-
           (SOCK_DGRAM) bzw. sequenzielles Paket- (SOCK_SEQPACKET) Socket gewartet werden soll.
           Die Adresse kann in verschiedenen Formaten geschrieben werden:

           Falls die Adresse mit einem Schrägstrich (»/«) beginnt, wird sie von einem
           Dateisystem-Socket in der Socket-Familie AF_UNIX gelesen.

           Falls die Adresse mit einem At-Zeichen (»@«) beginnt, wird sie als abstrakter
           Namensraum-Socket in der Familie AF_UNIX gelesen. Das »@« wird durch ein NUL vor der
           Anbindung ersetzt. Für Details siehe unix(7).

           Falls die Adresszeichenkette eine einzelne Zahl ist, wird sie als Nummer des Ports, an
           dem auf IPv6-Anfragen gewartet werden soll, gelesen. Abhängig vom Wert von
           BindIPv6Only= (siehe oben) könnte dies dazu führen, dass der Dienst sowohl auf IPv6
           und IPv4 (Vorgabe) oder nur IPv6 verfügbar ist.

           Falls die Adresszeichenkette im Format v.w.x.y:z vorliegt, wird sie als IPv4-Kennung
           zum Warten auf Anfragen auf Adresse v.w.x.y auf einem Port z gelesen.

           Falls die Adresszeichenkette im Format [x]:y vorliegt, wird sie als IPv6-Adresse auf
           einem Port y gelesen. Beachten Sie, dass dies den Dienst auch mittels IPv4 verfügbar
           machen könnte, abhängig von der Einstellung BindIPv6Only= (siehe unten).

           Falls die Adresszeichenkette im Format »vsock:x:y« vorliegt, wird sie als CID-Adresse
           »x« auf einem Port »y« in der Familie AF_VSOCK gelesen. Die CID ist eine eindeutige
           32-Bit-Ganzzahlkennung in AF_VSOCK, analog zu einer IP-Adresse. Die Angabe der CID ist
           optional und kann auf die leere Zeichenkette gesetzt werden.

           Beachten Sie, dass SOCK_SEQPACKET (d.h. ListenSequentialPacket=) nur für
           AF_UNIX-Sockets verfügbar ist. Wird SOCK_STREAM (d.h. ListenStream=) für IP-Sockets
           verwandt, dann bezieht es sich auf TCP-Sockets, SOCK_DGRAM (d.h. ListenDatagram=) auf
           UDP.

           Diese Optionen können mehr als einmal angegeben werden. In diesem Fall wird
           eingehender Verkehr auf einem der Sockets Dienste-Aktivierung auslösen und alle
           aufgeführten Sockets werden an den Dienst übergeben, unabhängig davon, ob es auf ihnen
           eingehenden Verkehr gibt oder nicht. Falls einer der Optionen die leere Zeichenkette
           zugewiesen wird, wird die Liste der Adressen, bei denen auf Anfragen gewartet werden
           soll, zurückgesetzt und alle vorherigen Verwendungen einer dieser Optionen werden
           keinen Effekt haben.

           Es ist auch möglich, bei der Verwendung von Service= mehr als eine Socket-Unit für den
           gleichen Dienst zu haben und der Dienst wird alle Sockets, die in allen Socket-Units
           konfiguriert sind, empfangen. Die in einer Unit konfigurierten Sockets werden in der
           Reihenfolge der Konfiguration weitergegeben, zwischen Socket-Units ist aber keine
           Ordnung festgelegt.

           Falls hier eine IP-Adresse verwandt wird, ist es oft wünschenswert, auf ihr auf
           Anfragen zu warten, bevor die Schnittstelle, auf der sie konfiguriert ist,
           hochgebracht und einsatzbereit ist und sogar unabhängig davon, ob sie zu irgendeinem
           Zeitpunkt hoch und einsatzbereit sein wird. Um damit umzugehen, wird empfohlen, die
           unten beschriebene Option FreeBind= zu setzen.

       ListenFIFO=
           Legt einen Dateisystem-FIFO fest, auf dem auf Anfragen gewartet wird. Dies erwartet
           einen absoluten Dateisystempfad als Argument. Das Verhalten ist ansonsten sehr ähnlich
           zu der Anweisung ListenDatagram= oben.

       ListenSpecial=
           Legt eine besondere Datei in dem Dateisystem fest, auf der auf Anfragen gewartet
           werden soll. Dies erwartet einen absoluten Dateisystempfad als Argument. Das Verhalten
           ist ansonsten sehr ähnlich zu der Anweisung ListenFIFO= oben. Verwenden Sie dies, um
           Zeichengeräteknoten sowie besondere Dateien in /proc und /sys zu öffnen.

       ListenNetlink=
           Legt eine Netlink-Familie fest, für die ein Socket erstellt werden soll, bei dem auf
           Anfragen gewartet werden soll. Dies erwartet eine kurze Zeichenkette, die sich auf den
           AF_NETLINK-Familiennamen bezieht (wie audit oder kobject-uevent), als Argument,
           optional kann ein Leerraumzeichen gefolgt von einer multicast-Gruppenganzzahl
           angehängt werden. Das Verhalten ist ansonsten sehr ähnlich zu der Anweisung
           ListenDatagram= oben.

       ListenMessageQueue=
           Legt einen POSIX-Nachrichtenwarteschlangennamen fest, bei dem auf Anfragen gewartet
           werden soll. Dies erwartet einen gültigen Nachrichtenwarteschlangennamen (d.h.
           anfangend mit /). Das Verhalten ist ansonsten sehr ähnlich zu der Anweisung
           ListenDatagram= oben. Unter Linux sind Nachrichtenwarteschlangendeskriptoren
           tatsächlich Dateideskriptoren und können zwischen Prozessen vererbt werden.

       ListenUSBFunction=
           Legt einen USB-FunctionFS[1]-Endpunktort zur Implementierung von USB-Gadget-Funktionen
           fest, auf dem auf Anfragen gewartet werden soll. Dies erwartet einen absoluten
           Dateisystempfad eines Functionfs-Einhängepunktes als Argument. Das Verhalten ist
           ansonsten ähnlich zu der Anweisung ListenFIFO= oben. Verwenden Sie dies, um den
           FunctionFS-Endpunkt ep0 zu öffnen. Wird diese Option verwandt, dann muss der
           aktivierte Dienst die Optionen USBFunctionDescriptors= und USBFunctionStrings= gesetzt
           haben.

       SocketProtocol=
           Akzeptiert entweder udplite oder sctp. Legt ein Socket-Protokoll (IPPROTO_UDPLITE)
           bzw. SCTP-Protokoll (IPPROTO_SCTP) fest.

       BindIPv6Only=
           Akzeptiert entweder default, both oder ipv6-only. Steuert die Socket-Option
           IPV6_V6ONLY (siehe ipv6(7) für Details). Falls both, werden IPv6-gebundene Sockets
           sowohl über IPv4 als auch IPv6 zugreifbar sein. Falls ipv6-only, werden sie nur über
           IPv6 zugreifbar sein. Falls default (was, Überraschung, die Vorgabe ist), wird die
           systemweite Voreinstellung, wie sie durch /proc/sys/net/ipv6/bindv6only gesteuert
           wird, die standardmäßig wiederum ein Äquivalent von both ist, verwandt.

       Backlog=
           Akzeptiert ein vorzeichenfreies Ganzzahlargument. Legt die Anzahl an Verbindungen, die
           noch nicht akzeptiert wurden und in die Warteschlange eingereiht werden sollen, fest.
           Diese Einstellung ist nur für Datenstrom- und sequenzielle Paket-Sockets relevant.
           Siehe listen(2) für Details. Standardmäßig SOMAXCONN (128).

       BindToDevice=
           Legt einen Netzwerkschnittstellennamen fest, an den dieses Socket gebunden werden
           soll. Falls gesetzt, wird Verkehr nur von der festgelegten Netzwerkschnittstelle
           akzeptiert. Dies steuert die Socket-Option SO_BINDTODEVICE (siehe socket(7) für
           Details). Falls diese Option verwandt wird, wird eine implizite Abhängigkeit von
           dieser Socket-Unit auf die Netzwerkschnittellen-Geräte-Unit (siehe systemd.device(5))
           erstellt. Beachten Sie, dass das Setzen dieses Parameters zur Ergänzung zusätzlicher
           Abhängigkeiten zu der Unit führen könnte (siehe oben).

       SocketUser=, SocketGroup=
           Akzeptiert einen UNIX-Benutzer-/Gruppennamen. Wenn festgelegt, gehören alle
           AF_UNIX-Sockets und FIFO-Knoten im Dateisystem dem festgelegten Benutzer und der
           festgelegten Gruppe. Falls nicht gesetzt (die Vorgabe), gehören die Knoten dem
           Benutzer/der Gruppe root (falls im Systemkontext ausgeführt) oder dem aufrufenden
           Benutzer/der aufrufenden Gruppe (falls im Benutzerkontext ausgeführt). Falls nur ein
           Benutzer aber keine Gruppe festgelegt ist, dann wird die Gruppe von der Standardgruppe
           des Benutzers abgeleitet.

       SocketMode=
           Falls auf einem Dateisystem-Socket oder FIFO auf Anfragen gewartet wird, legt diese
           Option den Dateisystemzugriffsmodus bei der Erzeugung des Dateiknotens fest.
           Akzeptiert einen Zugriffsmodus in oktaler Notation. Standardmäßig 0666.

       DirectoryMode=
           Falls auf einem Dateisystem-Socket oder FIFO auf Anfragen gewartet wird, werden die
           Elternknoten bei Bedarf automatisch erzeugt. Diese Option legt den
           Dateisystemzugriffsmodus bei der Erzeugung dieser Verzeichnisse fest. Akzeptiert einen
           Zugriffsmodus in oktaler Notation. Standardmäßig 0755.

       Accept=
           Akzeptiert ein logisches Argument. Falls wahr, wird für jede eingehende Verbindung
           eine Dienste-Instanz gestartet und nur der Verbindungs-Socket übergeben. Falls falsch,
           werden alle auf Anfragen wartende Sockets selbst an die startende Dienst-Unit
           übergeben und nur eine Dienste-Unit wird für alle Verbindungen gestartet (siehe auch
           oben). Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, wo eine einzelne
           Dienste-Unit bedingungslos allen eingehenden Verkehr bearbeitet. Standardmäßig false.
           Zur Erhöhung der Leistung wird empfohlen, neue Daemons nur so zu schreiben, dass sie
           für Accept=no geeignet sind. Ein Daemon, der auf einem AF_UNIX-Socket auf Anfragen
           wartet, kann, aber muss nicht, close(2) auf dem empfangenen Socket vor dem Beenden
           aufrufen. Allerdings darf er nicht mit unlink den Socket aus dem Dateisystem
           entfernen. Er sollte nicht auf mit gesetztem Accept=no erhaltenen Sockets shutdown(2)
           aufrufen, kann dies aber mit Sockets, bei denen Accept=yes gesetzt ist, machen. Das
           Setzen von Accept=yes ist hauptsächlich nützlich, um Daemons, die für die Verwendung
           mit inetd(8) entwickelt wurden, zu erlauben, unverändert mit
           Systemd-Socket-Aktivierung zu funktionieren.

           Für IPv4- und IPv6-Verbindungen wird die Umgebungsvariable REMOTE_ADDR die ferne
           IP-Adresse und REMOTE_PORT den fernen Port enthalten. Dies ist das gleiche Format wie
           von CGI benutzt. Für SOCK_RAW ist der Port das IP-Protokoll.

       Writable=
           Akzeptiert ein logisches Argument. Darf nur in Zusammenhang mit ListenSpecial=
           verwandt werden. Falls wahr, wird die festgelegte besondere Datei im
           Lese-/Schreibmodus geöffnet, falls falsch, im nur-Lesemodus. Standardmäßig falsch.

       MaxConnections=
           Die maximale Anzahl an Verbindungen, für die gleichzeitig Dienste-Instanzen ausgeführt
           werden sollen, wenn Accept=yes gesetzt ist. Falls mehr gleichzeitige Verbindungen
           eingehen, werden sie abgelehnt, bis mindestens eine bestehende Verbindung beendet ist.
           Diese Einstellung hat auf Sockets, die mit Accept=no konfiguriert sind oder
           Datagram-Sockets keinen Effekt. Standardmäßig 64.

       MaxConnectionsPerSource=
           Die maximale Anzahl an Verbindungen für einen Dienst pro Quell-IP-Adresse. Dies ist
           sehr ähnlich zu der Anweisung MaxConnections= oben. Standardmäßig deaktiviert.

       KeepAlive=
           Akzeptiert ein logisches Argument. Falls wahr, wird der TCP/IP-Stack eine
           Aufrechterhaltungsnachricht nach 2 Stunden (abhängig von der Konfiguration von
           /proc/sys/net/ipv4/tcp_keepalive_time) für alle TCP-Datenströme, die auf diesem Socket
           akzeptiert sind, senden. Dies steuert die Socket-Option SO_KEEPALIVE (siehe socket(7)
           und die Dokumentation TCP-Aufrechterhaltungs-HOWTO[2] für Details). Standardmäßig
           false.

       KeepAliveTimeSec=
           Akzeptiert Zeit (in Sekunden) als Argument. Die Verbindung muss im Leerlauf bleiben,
           bevor TCP das Senden von Aufrechterhaltungstestern beginnt. Dies steuert die
           Socket-Option TCP_KEEPIDLE (siehe socket(7) und das TCP-Aufrechterhaltungs-HOWTO[2]
           für Details). Standardwert ist 7200 Sekunden (2 Stunden).

       KeepAliveIntervalSec=
           Akzeptiert Zeit (in Sekunden) als Argument zwischen individuellen
           Aufrechterhaltungstestern, falls die Socket-Option SO_KEEPALIVE auf diesem Socket
           gesetzt wurde. Dies steuert die Socket-Option TCP_KEEPINTVL (siehe socket(7) und das
           TCP-Aufrechterhaltungs-HOWTO[2] für Details). Standardwert ist 75 Sekunden.

       KeepAliveProbes=
           Akzeptiert eine Ganzzahl als Argument. Sie ist die Anzahl von nicht bestätigten
           Testern, die gesandt werden müssen, bevor die Verbindung als tot betrachtet und die
           Anwendungsebene unterrichtet wird. Dies steuert die Socket-Option TCP_KEEPCNT (siehe
           socket(7) und das TCP-Aufrechterhaltungs-HOWTO[2] für Details). Standardwert ist 9.

       NoDelay=
           Akzeptiert ein logisches Argument. Der Nagle-Algorithmus von TCP funktioniert durch
           Kombination einer Reihe von kleinen ausgehenden Nachrichten und dem gemeinsamen
           Senden. Dies steuert die Socket-Option TCP_NODELAY (siehe tcp(7)). Standardmäßig
           false.

       Priority=
           Akzeptiert ein Ganzzahlargument, das die Priorität steuert, mit der sämtlicher Verkehr
           von diesem Socket gesandt wird. Dies steuert die Socket-Option SO_PRIORITY (siehe
           socket(7) für Details.).

       DeferAcceptSec=
           Akzeptiert eine Zeit (in Sekunden) als Argument. Falls gesetzt, wird der auf Anfragen
           wartende Prozess nur aufgeweckt, falls Daten auf dem Socket ankommen und nicht sofort,
           wenn die Verbindung etabliert wird. Wenn diese Option gesetzt ist, wird die
           Socket-Option TCP_DEFER_ACCEPT verwandt (siehe tcp(7)) und der Kernel wird anfängliche
           ACK-Pakete ohne Daten ignorieren. Das Argument legt die ungefähre Zeitdauer fest, die
           der Kernel auf eingehende Daten warten sollte, bevor er auf das normale Verhalten der
           Berücksichtigung leerer ACK-Pakete zurückfallen soll. Diese Option nützt bei
           Protokollen, bei denen der Client Daten zuerst sendet (z.B. HTTP im Gegensatz zu
           SMTP), da der Serverprozess nicht unnötigerweise aufgeweckt werden wird, bevor er
           irgendetwas erledigen kann.

           Falls der Client auch die Option TCP_DEFER_ACCEPT verwendet, wird die Latenz der
           anfänglichen Verbindung auch reduziert, da der Kernel die Daten im abschließenden
           Paket des Verbindungsaufbaus (dem dritten Paket der Dreiwege-Datenflusssteuerung)
           senden wird.

           Standardmäßig deaktiviert.

       ReceiveBuffer=, SendBuffer=
           Akzeptiert ein Ganzzahlargument, das die Empfangs- bzw. Sendepuffergröße des Sockets
           steuert. Dies steuert die Socket-Optionen SO_RCVBUF und SO_SNDBUF (siehe socket(7) für
           Details.). Die normalen Endungen K, M, G werden unterstützt und zur Basis 1024
           interpretiert.

       IPTOS=
           Akzeptiert ein Ganzzahlargument, das das IP-Feld »Type-Of-Service« für von diesem
           Socket erstellte Pakete steuert. Dies steuert die Socket-Option IP_TOS (siehe ip(7)
           für Details.). Es kann entweder eine numerische Zeichenkette oder low-delay,
           throughput, reliability oder low-cost festgelegt werden.

       IPTTL=
           Akzeptiert ein Ganzzahlargument, das das IPv4-Feld »Time-To-Live/IPv6 Hop-Count« für
           von diesem Socket erstellte Pakete steuert. Dies steuert die Socket-Option
           IPV6_UNICAST_HOPS (siehe ip(7) und ipv6(7) für Details.).

       Mark=
           Akzeptiert einen Ganzzahlwert. Steuert die Firewall-Markierung von durch dieses Socket
           generierten Paketen. Dies kann in der Firewall-Logik zur Filterung von Paketen von
           diesem Socket verwandt werden. Dies setzt die Socket-Option SO_MARK. Siehe iptables(8)
           für Details.

       ReusePort=
           Akzeptiert einen logischen Wert. Falls wahr, werden mehrere bind(2)s auf diesen TCP-
           oder UDP-Port erlaubt. Dies steuert die Socket-Option SO_REUSEPORT. Siehe socket(7)
           für Details.

       SmackLabel=, SmackLabelIPIn=, SmackLabelIPOut=
           Akzeptiert einen Zeichenkettenwert. Steuert die erweiterten Attribute
           »security.SMACK64«, »security.SMACK64IPIN« bzw. »security.SMACK64IPOUT«, d.h. dem
           Sicherheits-Label des FIFO oder dem Sicherheits-Label für eingehende bzw. ausgehende
           Verindungen auf dem Socket. Siehe Smack.txt[3] für Details.

       SELinuxContextFromNet=
           Akzeptiert ein logisches Argument. Falls wahr, wird Systemd versuchen, das für den
           instanziierten Dienst verwandte SELinux-Label aus den vom Peer über das Netzwerk
           übergebenen Informationen herauszufinden. Beachten Sie, dass von den vom Peer
           übergebenen Informationen nur die Sicherheitsstufe verwandt wird. Andere Anteile des
           ergebenen SELinux-Kontextes stammen entweder vom Zielprogramm, das effektiv vom Socket
           ausgelöst wird, oder aus dem Wert der Option SELinuxContext=. Diese
           Konfigurationsoption betrifft nur Sockets, bei denen der Modus Accept= auf »true«
           gesetzt ist. Beachten Sie auch, dass diese Option nur nützlich ist, wenn eine
           MLS/MCS-SELinux-Richtlinie eingesetzt wird. Standardmäßig »false«.

       PipeSize=
           Akzeptiert eine Größe in Bytes. Steuert die Pipepuffergröße der FIFOs, die in dieser
           Socket-Unit konfiguriert werden. Siehe fcntl(2) für Details. Die normalen Endungen K,
           M, G werden unterstützt und zur Basis 1024 interpretiert.

       MessageQueueMaxMessages=, MessageQueueMessageSize=
           Diese zwei Felder akzeptieren Ganzzahlwerte und steuern beim Erstellen der
           Nachrichtenwarteschlange das Feld mq_maxmsg bzw. mq_msgsize. Beachten Sie, dass
           entweder keine oder beide der Variablen gesetzt werden müssen. Siehe mq_setattr(3) für
           Details.

       FreeBind=
           Akzeptiert einen logischen Wert. Steuert, ob der Socket an eine nichtlokale IP-Adresse
           gebunden werden kann. Dies ist nützlich, um Sockets zu konfigurieren, die auf einer
           bestimmten IP-Adresse auf Anfragen warten sollen, bevor diese IP-Adresse erfolgreich
           auf einer Netzwerkschnittstelle konfiguriert wurde. Dies richtet die Socket-Option
           IP_FREEBIND ein. Aus Robustheitsgründen wird empfohlen, diese Option immer zu
           benutzen, wenn Sie ein Socket an eine bestimmte IP-Adresse binden. Standardmäßig
           false.

       Transparent=
           Akzeptiert einen logischen Wert. Steuert die Socket-Option IP_TRANSPARENT.
           Standardmäßig false.

       Broadcast=
           Akzeptiert einen logischen Wert. Dies steuert die Socket-Option SO_BROADCAST, die das
           Senden von Datagrammen von diesem Socket erlaubt. Standardmäßig false.

       PassCredentials=
           Akzeptiert einen logischen Wert. Dies steuert die Socket-Option SO_PASSCRED, die
           AF_UNIX-Sockets den Empfang von Berechtigungsnachweisen vom sendenden Prozess in einer
           Hilfsnachricht erlaubt. Standardmäßig false.

       PassSecurity=
           Akzeptiert einen logischen Wert. Dies steuert die Socket-Option SO_PASSSEC, die
           AF_UNIX-Sockets den Empfang des Sicherheitskontextes vom sendenden Prozess in einer
           Hilfsnachricht erlaubt. Standardmäßig false.

       TCPCongestion=
           Akzeptiert einen Zeichenkettenwert. Steuert den von diesem Socket verwandten
           TCP-Überlastungsalgorithmus. Sollte entweder »westwood«, »veno«, »cubic«, »lp« oder
           jeder andere vom IP-Stack verfügbare Algorithmus sein. Diese Einstellung gilt nur für
           Datenstrom-Sockets.

       ExecStartPre=, ExecStartPost=
           Akzeptiert eine oder mehrere Befehlszeilen, die ausgeführt werden, vor bzw. nachdem
           der auf Anfragen wartende Socket/FIFO erstellt und gebunden wurde. Das erste Symbol
           auf der Befehlszeile muss ein absoluter Dateiname sein, dem die Argumente für den
           Prozess folgen. Gemäß des für ExecStartPre= bei Dienste-Unit-Dateien verwandten
           Schematas können mehrere Befehlszeilen festgelegt werden.

       ExecStopPre=, ExecStopPost=
           Zusätzliche Befehle, die ausgeführt werden, vor bzw. nachdem der auf Anfragen wartende
           Socket/FIFO geschlossen und entfernt wurde. Gemäß des für ExecStartPre= bei
           Dienste-Unit-Dateien verwandten Schematas können mehrere Befehlszeilen festgelegt
           werden.

       TimeoutSec=
           Konfiguriert die Zeit, die auf das Beenden der in ExecStartPre=, ExecStartPost=,
           ExecStopPre= und ExecStopPost= festgelegten Befehle gewartet wird. Falls ein Befehl
           sich nicht innerhalb der konfigurierten Zeit beendet, wird der Socket als
           fehlgeschlagen betrachtet und wieder heruntergefahren. Alle noch laufenden Befehle
           werden zwangsweise mittels SIGTERM und nach einer weiteren Verzögerung dieser
           Zeitdauer mit SIGKILL beendet. (Siehe KillMode= in systemd.kill(5).) Akzeptiert einen
           einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie »5min 20s«. Durch
           Übergabe von »0« wird die Zeitüberschreitungslogik deaktiviert. Standardmäßig
           DefaultTimeoutStartSec= aus der Verwalterkonfigurationsdatei (siehe
           systemd-system.conf(5)).

       Service=
           Legt den bei eingehendem Verkehr zu aktivierenden Dienste-Unit-Namen fest. Diese
           Einstellung ist nur für Sockets mit Accept=no erlaubt. Standardmäßig wird der Dienst
           verwandt, der den gleichen Namen wie das Socket trägt (mit entfernter Endung).
           Meistens sollte es nicht notwendig sein, diese Option zu verwenden. Beachten Sie, dass
           Setzen dieses Parameters zur Hinzunahme zusätzlicher Abhängigkeiten führen kann (siehe
           oben).

       RemoveOnStop=
           Akzeptiert ein logisches Argument. Falls aktiviert, werden alle von dieser Socket-Unit
           erstellten Dateiknoten entfernt, wenn diese gestoppt wird. Dies gilt für
           AF_UNIX-Sockets im Dateisystem, POSIX-Nachrichtenwarteschlangen, FIFOs sowie allen
           Symlinks auf sie, die mit Symlinks= konfiguriert sind. Normalerweise sollte es nicht
           notwendig sein, diese Option zu verwenden. Die Verwendung dieser Option wird auch
           nicht empfohlen, da Dienste weiterlaufen könnten, nachdem die Socket-Unit beendet
           wurde und es sollte weiterhin möglich sein, mit ihnen über den Dateisystemknoten zu
           kommunizieren. Standardmäßig aus.

       Symlinks=
           Akzeptiert eine Liste von Dateisystempfaden. Die festgelegten Pfade werden als
           Symlinks auf den AF_UNIX-Socket-Pfad oder FIFO-Pfad von dieser Socket-Unit erstellt.
           Falls diese Einstellung verwandt wird, kann nur ein AF_UNIX-Socket in diesem
           Dateisystem oder ein FIFO für die Socket-Unit konfiguriert sein. Verwenden Sie diese
           Option, um einen oder mehrere Symlink-Aliasnamen für einen Socket zu verwalten und
           ihren Lebenszyklus zu verknüpfen. Beachten Sie, dass es für die Socket-Unit nicht als
           fatal betrachtet wird, wenn die Erstellung eines Symlinks fehlschlägt und die
           Socket-Unit weiterhin starten könnte. Falls eine leere Zeichenkette zugewiesen wird,
           wird die Liste der Pfade zurückgesetzt. Standardmäßig eine leere Liste.

       FileDescriptorName=
           Weist allen Dateideskriptoren, die diese Socket-Unit kapselt, einen Namen zu. Dies
           hilft aktivierten Diensten bei der Erkennung bestimmter Dateideskriptoren, falls
           mehrere Dateideskriptoren übergeben werden. Dienste können den Aufruf
           sd_listen_fds_with_names(3) verwenden, um den konfigurierten Namen für die empfangenen
           Dateideskriptoren zu erlangen. Die Namen dürfen jedes ASCII-Zeichen enthalten,
           allerdings keine Steuerzeichen und »:«, und dürfen höchstens 255 Zeichen lang sein.
           Falls diese Einstellung nicht verwandt wird, ist die Vorgabe für Dateideskriptoren der
           Name der Socket-Unit, einschließlich ihrer Endung .socket.

       TriggerLimitIntervalSec=, TriggerLimitBurst=
           Konfiguriert eine Begrenzung, wie oft diese Socket-Unit innerhalb eines bestimmten
           Zeitintervalls aktiviert werden darf. Die Länge des Zeitintervalls in den normalen
           Zeiteinheiten »us«, »ms«, »s«, »min«, »h«, … kann mit TriggerLimitIntervalSec=
           konfiguriert werden, die Vorgabe ist 2s (siehe systemd.time(7) für Details über die
           verschiedenen verstandenen Zeiteinheiten). Die Einstellung TriggerLimitBurst=
           akzeptiert einen positiven Ganzzahlwert und legt die Anzahl der erlaubten
           Aktivierungen pro Zeiteinheit fest, die Vorgabe ist 200 für Sockets mit Accept=yes
           (daher werden standardmäßig 200 Aktivierungen pro 2 Sekunden erlaubt) und andernfalls
           20 (20 Aktivierungen pro 2 Sekunden). Setzen Sie einen der beiden auf 0, um jede Art
           der Auslöseratenbegrenzung zu deaktivieren. Falls diese Begrenzung erreicht wird, wird
           die Socket-Unit in den Fehlerzustandmodus gebracht und Verbindungen zu ihr sind nicht
           mehr möglich, bis sie neu gestartet wird. Beachten Sie, dass diese Begrenzung
           erzwungen wird, bevor die Diensteaktivierung in die Warteschlange eingereiht wird.

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

SIEHE AUCH

       systemd(1), systemctl(1), systemd-system.conf(5), systemd.unit(5), systemd.exec(5),
       systemd.kill(5), systemd.resource-control(5), systemd.service(5), systemd.directives(7),
       sd_listen_fds(3), sd_listen_fds_with_names(3)

       Für eine ausführlichere Beschreibung siehe die Serie »Systemd für Entwickler«:
       Socket-Aktivierung[4], Socket-Aktivierung, Teil II[5], Inetd-Dienste konvertieren[6],
       Socket-aktivierte Internet-Dienste und Betriebssystem-Container[7].

ANMERKUNGEN

        1. USB FunctionFS
           https://www.kernel.org/doc/Documentation/usb/functionfs.txt

        2. TCP-Aufrechterhaltungs-HOWTO
           http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

        3. Smack.txt
           https://www.kernel.org/doc/Documentation/security/Smack.txt

        4. Socket-Aktivierung
           http://0pointer.de/blog/projects/socket-activation.html

        5. Socket-Aktivierung, Teil II
           http://0pointer.de/blog/projects/socket-activation2.html

        6. Inetd-Dienste-Konvertierung
           http://0pointer.de/blog/projects/inetd.html

        7. Socket-aktivierte Internet-Dienste und Betriebssystem-Container
           http://0pointer.de/blog/projects/socket-activated-containers.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 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>.