systemd.socket

SYSTEMD.SOCKET(5)                systemd.socket                SYSTEMD.SOCKET(5)



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-Unit muss eine passende Dienste-Unit existieren, die den
       bei eingehendem Verkehr auf dem Socket zu startenden Dienst beschreibt
       (siehe systemd.service(5) für weitere Informationen über .service-Units).
       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
       Dienstevorlage-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 über das
       genau verwandte Protokoll und die Reihenfolge, in der die
       Dateideskriptoren übergeben werden) 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. Das Socket wird das
           UDP-Lite-(IPPROTO_UDPLITE) bzw. SCP-Protokoll (IPPROTO_SCTP)
           verwenden.

       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.

       PassPacketInfo=
           Akzeptiert einen logischen Wert. Dies steuert die Socket-Optionen
           IP_PKTINFO, IPV6_RECVPKTINFO und NETLINK_PKTINFO, die dem Empfang
           zusätzlicher, paketbezogener Metadaten auf den Sockets AF_INET,
           AF_INET6 und AF_UNIX als Zusatznachrichten aktivieren. 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>.



systemd 246                                                    SYSTEMD.SOCKET(5)