Ubuntu Manpage: systemd.socket - Socket-Unit-Konfiguration

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 verlinkten Blog-Einträgen für eine
Einführung.

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, entweder 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 sehr 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-Unit-Datei können Abschnitte [Unit] und [Install] enthalten, die in systemd.unit(5) beschrieben
sind.

Socket-Unit-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),
systemd.kill(5) und systemd.resource-control(5) dokumentiert. Die für den Abschnitt »[Socket]« in
Socket-Units speziellen Optionen sind die folgenden:

ListenStream=, ListenDatagram=, ListenSequentialPacket=
Gibt eine Adresse an, auf 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-Adresse v.w.x.y und
Port z interpretiert.

Falls die Adresszeichenkette im Format »[x]:y« vorliegt, wird sie als IPv6-Adresse x und Port y
interpretiert. Ein optionaler Schnittstellengeltungsbereich (Schnittstellenname oder -nummer) kann
nach einem »%«-Symbol angegeben werden: »[x]:y%dev«. Schnittstellengeltungsbereiche sind nur für
linklokale Adressen nützlich, da der Kernel sie in anderen Fällen ignoriert. Beachten Sie, dass der
Dienst auch via IPv4 verfügbar gemacht werden könnte, wenn eine Adresse als IPv6 spezifiziert wurde,
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. »vsock« kann durch »vsock-stream«, »vsock-dgram« oder »vsock-seqpacket«
ersetzt werden, um die Verwendung des entsprechenden Socket-Typs zu erzwingen.

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=
Gibt einen Dateisystem-FIFO (siehe fifo(7) für Details) an, 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=
Gibt eine besondere Datei in dem Dateisystem an, 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=
Gibt eine Netlink-Familie an, 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=
Gibt einen POSIX-Nachrichtenwarteschlangennamen an, bei dem auf Anfragen gewartet werden soll (siehe
mq_overview(7) für Details). 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=
Gibt einen USB-FunctionFS[1]-Endpunktort zur Implementierung von USB-Gadget-Funktionen an, 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.

Hinzugefügt in Version 227.

SocketProtocol=
Akzeptiert entweder udplite, sctp oder mptcp. Das Socket wird das UDP-Lite- (IPPROTO_UDPLITE), SCTP-
(IPPROTO_SCTP) bzw. SCP-Protokoll (IPPROTO_SCTP) verwenden.

Hinzugefügt in Version 229.

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, 32-bit Ganzzahlargument. Gibt die Anzahl an Verbindungen, die noch
nicht akzeptiert wurden und in die Warteschlange eingereiht werden sollen, an. Diese Einstellung ist
nur für Datenstrom- und sequenzielle Paket-Sockets relevant. Siehe listen(2) für Details.
Standardmäßig 4294967295. Beachten Sie, dass dieser Wert ohne Rückmeldung durch den Sysctl
»net.core.somaxconn« nach oben begrenzt wird, standardmäßig liegt er bei 4096, daher ist
typischerweise die Sysctl-Einstellung relevant.

BindToDevice=
Gibt einen Netzwerkschnittstellennamen an, an den dieses Socket gebunden werden soll. Falls gesetzt,
wird Verkehr nur von der angegebenen 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 angegeben, gehören alle AF_UNIX-Sockets,
FIFO-Knoten und Nachrichtenwarteschlangen im Dateisystem dem angegebenen Benutzer und der angegebenen
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 angegeben ist, dann wird die
Gruppe von der Standardgruppe des Benutzers abgeleitet.

Hinzugefügt in Version 214.

SocketMode=
Falls auf einem Dateisystem-Socket, FIFO oder Nachrichtenwarteschlange auf Anfragen gewartet wird,
gibt diese Option den Dateisystemzugriffsmodus bei der Erzeugung des Dateiknotens an. 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 gibt den Dateisystemzugriffsmodus bei der Erzeugung dieser
Verzeichnisse an. Akzeptiert einen Zugriffsmodus in oktaler Notation. Standardmäßig 0755.

Accept=
Akzeptiert ein logisches Argument. Falls yes, wird für jede eingehende Verbindung eine
Dienste-Instanz gestartet und nur der Verbindungs-Socket übergeben. Falls no, 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 no. 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.

Beachten Sie, dass abhängig von dieser Einstellung die von Units mit diesem Typ aktivierten Dienste
entweder reguläre Dienste (im Falle von Accept=no) oder Instanzen von vorlagenbasierten Diensten (im
Falle von Accept=yes) sind. Siehe den obigen Abschnitt Beschreibung für eine detailliertere
Diskussion der Benennungsregeln für ausgelöste Dienste.

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 AF_UNIX-Socket-Verbindungen wird die Umgebungsvariable $REMOTE_ADDR entweder den fernen
Socket-Dateisystempfad, beginnend mit einem Schrägstrich (»/«), oder seine Adresse in dem abstrakten
Namensraum, beginnend mit einem At-Zeichen (»@«), enthalten. Falls der Socket keinen Namen hat, wird
$REMOTE_ADDR nicht gesetzt.

Es wird empfohlen, für mittels Accept=yes aktivierte Diensteinstanzen CollectMode=inactive-or-failed
zu setzen, um sicherzustellen, dass fehlgeschlagene Verbindungsdienste bereinigt und deren Speicher
freigegeben werden und sich nicht ansammeln.

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

Hinzugefügt in Version 227.

FlushPending=
Akzeptiert ein logisches Argument. Darf nur bei Accept=no verwandt werden. Falls »yes«, werden die
Puffer des Sockets bereinigt, nachdem sich der ausgelöste Dienst beendet hat. Damit werden sämtliche
anhängige Daten rausgeschrieben und anhängende eingehende Verbindungen abgelehnt. Falls »no«, werden
die Puffer des Sockets nicht bereinigt, wodurch dem Dienst ermöglicht wird, sämtliche anhängende
Verbindungen nach dem Neustart zu bedienen, was das normalerweise erwartete Verhalten darstellt.
Standardmäßig no.

Hinzugefügt in Version 247.

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 (im Falle von IPv4/IPv6),
pro Quell-CID (im Falle von AF_VSOCK) oder pro Quell-UID (im Falle von AF_UNIX). Dies ist sehr
ähnlich zu der Anweisung MaxConnections= oben. Standardmäßig 0, d.h. deaktiviert.

Hinzugefügt in Version 232.

KeepAlive=
Akzeptiert ein logisches Argument. Falls true, 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).

Hinzugefügt in Version 216.

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.

Hinzugefügt in Version 216.

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.

Hinzugefügt in Version 216.

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.

Hinzugefügt in Version 216.

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 gibt
die ungefähre Zeitdauer an, 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.

Hinzugefügt in Version 216.

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 angegeben 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 IP_TTL/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 true, 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.

Hinzugefügt in Version 206.

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[3] für
Details.

Hinzugefügt in Version 196.

SELinuxContextFromNet=
Akzeptiert ein logisches Argument. Falls true, 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 ist nur anwendbar, wenn der aktivierte Dienst in einem einzelnen
Socket-Dateideskriptor übergeben wird, d.h. die Dienste-Instanzen, bei denen die Standardeingabe mit
einem Socket verbunden ist oder Dienste, die durch genau eine Socket-Unit ausgelöst werden. Beachten
Sie auch, dass diese Option nur nützlich ist, wenn eine MLS/MCS-SELinux-Richtlinie eingesetzt wird.
Standardmäßig »false«.

Hinzugefügt in Version 217.

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/IPV6_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/IPV6_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,
NETLINK_PKTINFO oder PACKET_AUXDATA, die dem Empfang zusätzlicher, paketbezogener Metadaten auf den
Sockets AF_INET, AF_INET6, AF_UNIX und AF_PACKET als Zusatznachrichten aktivieren. Standardmäßig
false.

Hinzugefügt in Version 246.

Timestamping=
Akzeptiert entweder »off«, »us« (Alias: »usec«, »µs«) oder »ns« (Alias: »nsec«). Dies steuert die
Socket-Optionen SO_TIMESTAMP oder SO_TIMESTAMPNS und aktiviert, ob eingehender Netzwerkverkehr
Zeitstempel-Metadaten transportieren soll. Standardmäßig off.

Hinzugefügt in Version 247.

TCPCongestion=
Akzeptiert einen Zeichenkettenwert. Steuert den von diesem Socket verwandten
TCP-Überlastungsalgorithmus. Sollte entweder »westwood«, »reno«, »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 angegeben 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 angegeben 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=
Gibt den bei eingehendem Verkehr zu aktivierenden Dienste-Unit-Namen an. 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.

Hinzugefügt in Version 214.

Symlinks=
Akzeptiert eine Liste von Dateisystempfaden. Die angegebenen 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.

Hinzugefügt in Version 214.

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), wenn Accept=no, ansonsten »connection«.

Hinzugefügt in Version 227.

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 der Einstellung 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.

Vergleichen Sie das mit dem nachfolgend beschriebenen PollLimitIntervalSec=/PollLimitBurst=, der eine
temporäre Verlangsamung implementiert, falls eine Socket-Unit mit eingehendem Verkehr geflutet wird,
im Gegenteil zum dauerhaften Fehlzustand, zu dem TriggerLimitIntervalSec=/TriggerLimitBurst= führt.

Hinzugefügt in Version 230.

PollLimitIntervalSec=, PollLimitBurst=
Konfiguriert eine Beschränkung, wie oft Polling-Ereignisse für den dieser Unit zugrundeliegenden
Dateideskriptoren berücksichtigt werden. Dieses Paar von Einstellungen ist ähnlich
TriggerLimitIntervalSec=/TriggerLimitBurst=, aber anstatt eine (fatale) Beschränkung auf die
Aktivierungsfrequenz zu legen, wird eine (vorübergehende) Beschränkung auf die Polling-Frequenz
gelegt. Die erwartete Parametersyntax und -bereich sind identisch zu den vorgenannten Optionen, und
kann auf die gleiche Art deaktiviert werden.

Falls die Polling-Beschränkung erreicht wird, wird Polling vorübergehend darauf deaktiviert, bis das
festgelegte Fenster verstrichen ist. Die Polling-Beschränkung verlangsamt daher nach Erreichen die
Verbindungsversuche, führt aber anders als die Auslösebeschränkung nicht zu einem dauerhaften
Fehlschlag. Es ist der empfohlene Mechanismus, um mit DoS-Versuchen mittels Paket-Flutung umzugehen.

Die Polling-Beschränkung wird pro Dateideskriptor, bei dem auf Anfragen gewartet wird, durchgesetzt,
anders als bei der Auslösebeschränkung, die für die gesamte Socket-Unit durchgesetzt wird. Diese
Beschränkung ist für Socket-Units wichtig, die auf mehreren Dateideskriptoren auf Anfragen warten
(d.h. die über mehrere Absätze ListenXYZ= verfügen).

Diese Einstellungen betragen standardmäßig 150 (im Falle von Accept=yes=) und (andernfalls) 15
Polling-Ereignisse pro 2s. Dies ist beträchtlich niedriger als die Vorgabewerte für die
Auslösungsbeschränkung (siehe oben) und bedeutet, dass die Polling-Beschränkung typischerweise
sicherstellen soll, dass die Auslösebeschränkung niemals erreicht wird, außer eine von ihnen ist
rekonfiguriert oder deaktiviert.

Hinzugefügt in Version 255.

PassFileDescriptorsToExec=
Akzeptiert ein logisches Argument. Standardmäßig aus. Falls aktiviert, werden von der Socket-Unit
erstellte Dateideskriptoren an die Befehle ExecStartPost=, ExecStopPre= und ExecStopPost= von der
Socket-Unit weitergegeben. Auf die übergebenen Dateideskriptoren kann mit sd_listen_fds(3)
zugegriffen werden, also ob die Befehle von den zugehörigen Dienste-Units aufgerufen worden wären.
Beachten Sie, dass der Befehl ExecStartPre= nicht auf Socket-Dateideskriptoren zugreifen kann.

Hinzugefügt in Version 256.

Lesen Sie systemd.unit(5), 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://docs.kernel.org/usb/functionfs.html

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

        3. Smack
           https://docs.kernel.org/admin-guide/LSM/Smack.html

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

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

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

        7. Socket-aktivierte Internet-Dienste und Betriebssystem-Container
           https://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  die
       Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.

systemd 257.6                                                                                  SYSTEMD.SOCKET(5)