SYSTEMD.SOCKET(5) systemd.socket SYSTEMD.SOCKET(5) BEZEICHNUNG systemd.socket - Socket-Unit-Konfiguration UBERSICHT Socket.socket BESCHREIBUNG Eine Unit-Konfigurationsdatei, deren Namen in >>.socket<< endet, kodiert Informationen uber einen IPC oder Netzwerk-Socket oder ein Dateisystem-FIFO, der von Systemd gesteuert und uberwacht wird, fur Socket-basierte Aktivierung. Diese Handbuchseite fuhrt die fur diesen Unit-Typ spezifischen Konfigurationsoptionen auf. Siehe systemd.unit(5) fur die gemeinsamen Optionen aller Unit-Konfigurationsdateien. Die gemeinsamen Konfigurationseintrage werden in den generischen Abschnitten >>[Unit]<< und >>[Install]<< konfiguriert. Die Socket-spezifischen Konfigurationsoptionen werden in dem Abschnitt >>[Socket]<< konfiguriert. Zusatzliche Optionen sind in systemd.exec(5), das die Ausfuhrungsumgebung, in der die Befehle ExecStartPre=, ExecStartPost=, ExecStopPre= und ExecStopPost= ausgefuhrt werden und in systemd.kill(5), das die Art der Beendigung der Prozesse definiert und in systemd.resource-control(5), das die Ressourcensteuerungseinstellungen fur die Prozesse des Sockets konfiguriert, aufgefuhrt. Fur 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) fur weitere Informationen uber .service-Units). Der Name der .service-Unit ist standardmassig der gleiche wie der Name der .socket-Unit, dies kann aber mit der weiter unten beschriebenen Option Service= verandert werden. Abhangig von den Einstellungen der unten beschriebenen Option Accept= muss diese Dienste-Unit entweder wie die .socket-Unit (aber mit ersetzter Endung) benannt sein, ausser dies wird mit Service= ausser Kraft gesetzt, oder sie muss eine Vorlagen-Unit sein, die auf die gleiche Art benannt ist. Beispiel: Eine Socket-Datei foo.socket benotigt 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 fur jede eingehende Verbindung instanziiert werden. Es wird keine implizite Abhangigkeit WantedBy= oder RequiredBy= vom Socket auf den Dienst hinzugefugt. Dies bedeutet, dass der Dienst ohne den Socket gestartet werden darf. In diesem Fall muss er in der Lage sein, den Socket selbst zu offnen. Um dies zu verhindern, kann eine explizite Abhangigkeit Requires= hinzugefugt werden. Socket-Units konnen zur Implementierung des bedarfsorientierten Startens von Diensten sowie zum parallelen Starten von Diensten verwandt werden. Siehe die am Ende verlinkten Blog-Eintragen fur eine Einfuhrung. Beachten Sie, dass Daemon-Software, die fur Socket-Aktivierung mit Socket-Units konfiguriert ist, in der Lage sein muss, Sockets von Systemd zu akzeptieren, entweder mittels Systemds nativer Socket-Ubergabeschnittstelle (siehe sd_listen_fds(3) fur Details uber das genau verwandte Protokoll und die Reihenfolge, in der die Dateideskriptoren ubergeben werden) oder mittels traditioneller inetd(8)-artiger Socket-Ubergabe (d.h. Sockets, die uber Standardein- und -ausgabe mittels StandardInput=socket in der Dienstedatei ubergeben 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 unterstutzt und ist sogar gangige 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, wahrend alle Sockets, die vom Dienste-Code selbst bereitgestellt werden, dem Namensraum des Dienstes selbst zugeordnet sind und daher moglicherweise einer sehr deutlich restriktiveren Konfiguration unterliegen konnten. AUTOMATISCHE ABHANGIGKEITEN Implizite Abhangigkeiten Die folgenden Abhangigkeiten werden implizit hinzugefugt: o Socket-Units erhalten automatisch eine Abhangigkeit Before= auf die von ihnen aktivierten Dienste-Units. o Socket-Units, die sich auf Dateisystempfade beziehen (wie AF_UNIX-Sockets oder FIFOs) erhalten implizit eine Abhangigkeit Requires= und After= auf alle fur den Zugriff auf diese Pfade notwendigen Einhange-Units. o Socket-Units, die die Einstellung BindToDevice= verwenden, erhalten automatisch Abhangigkeiten BindsTo= und After= von der Gerate-Unit, die die festgelegte Netzwerkschnittstelle kapselt. Zusatzliche implizite Abhangigkeiten als Ergebnis der Ausfuhrung und der gemass systemd.exec(5) und systemd.resource-control(5) dokumentierten Ressourcen-Steuerungsparameter konnen hinzugefugt werden. Standardabhangigkeiten Die folgenden Abhangigkeiten werden hinzugefugt, es sei denn, DefaultDependencies=no ist gesetzt: o Socket-Units erhalten automatisch eine Abhangigkeit Before= von sockets.target. o Socket-Units erhalten automatisch ein Abhangigkeitspaar After= und Requires= von sysinit.target und ein Abhangigkeitspaar Before= und Conflicts= von shutdown.target. Diese Abhangigkeiten stellen sicher, dass die Socket-Unit vor den normalen Diensten beim Systemstart gestartet und beim Herunterfahren beendet wird. Nur Sockets, die in der fruhen Systemstartphase oder spat beim Herunterfahren beteiligt sind, sollten die Option DefaultDependencies= deaktivieren. OPTIONEN Socket-Unit-Datei konnen Abschnitte [Unit] und [Install] enthalten, die in systemd.unit(5) beschrieben sind. Socket-Unit-Dateien mussen einen Abschnitt >>[Socket]<< enthalten, der Informationen uber das uberwachte Socket oder den uberwachten FIFO weitergibt. Eine Reihe von Optionen, die in diesem Abschnitt angegeben werden konnen, werden auch von anderen Unit-Typen verwandt. Diese Optionen sind in systemd.exec(5) und systemd.kill(5) dokumentiert. Die fur den Abschnitt >>[Socket]<< in Socket-Units speziellen Optionen sind die folgenden: ListenStream=, ListenDatagram=, ListenSequentialPacket= Gibt eine Adresse an, auf der auf Anfragen fur 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 Schragstrich (>>/<<) 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. Fur 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. Abhangig vom Wert von BindIPv6Only= (siehe oben) konnte dies dazu fuhren, dass der Dienst sowohl auf IPv6 und IPv4 (Vorgabe) oder nur IPv6 verfugbar 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 fur linklokale Adressen nutzlich, da der Kernel sie in anderen Fallen ignoriert. Beachten Sie, dass der Dienst auch via IPv4 verfugbar gemacht werden konnte, wenn eine Adresse als IPv6 spezifiziert wurde, abhangig 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 fur AF_UNIX-Sockets verfugbar ist. Wird SOCK_STREAM (d.h. ListenStream=) fur IP-Sockets verwandt, dann bezieht es sich auf TCP-Sockets, SOCK_DGRAM (d.h. ListenDatagram=) auf UDP. Diese Optionen konnen mehr als einmal angegeben werden. In diesem Fall wird eingehender Verkehr auf einem der Sockets Dienste-Aktivierung auslosen und alle aufgefuhrten Sockets werden an den Dienst ubergeben, unabhangig 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, zuruckgesetzt und alle vorherigen Verwendungen einer dieser Optionen werden keinen Effekt haben. Es ist auch moglich, bei der Verwendung von Service= mehr als eine Socket-Unit fur 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 wunschenswert, auf ihr auf Anfragen zu warten, bevor die Schnittstelle, auf der sie konfiguriert ist, hochgebracht und einsatzbereit ist und sogar unabhangig 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) fur Details) an, auf dem auf Anfragen gewartet wird. Dies erwartet einen absoluten Dateisystempfad als Argument. Das Verhalten ist ansonsten sehr ahnlich 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 ahnlich zu der Anweisung ListenFIFO= oben. Verwenden Sie dies, um Zeichengerateknoten sowie besondere Dateien in /proc/ und /sys/ zu offnen. ListenNetlink= Gibt eine Netlink-Familie an, fur 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 angehangt werden. Das Verhalten ist ansonsten sehr ahnlich zu der Anweisung ListenDatagram= oben. ListenMessageQueue= Gibt einen POSIX-Nachrichtenwarteschlangennamen an, bei dem auf Anfragen gewartet werden soll (siehe mq_overview(7) fur Details). Dies erwartet einen gultigen Nachrichtenwarteschlangennamen (d.h. anfangend mit >>/<<). Das Verhalten ist ansonsten sehr ahnlich zu der Anweisung ListenDatagram= oben. Unter Linux sind Nachrichtenwarteschlangendeskriptoren tatsachlich Dateideskriptoren und konnen 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-Einhangepunktes als Argument. Das Verhalten ist ansonsten ahnlich zu der Anweisung ListenFIFO= oben. Verwenden Sie dies, um den FunctionFS-Endpunkt ep0 zu offnen. Wird diese Option verwandt, dann muss der aktivierte Dienst die Optionen USBFunctionDescriptors= und USBFunctionStrings= gesetzt haben. Hinzugefugt in Version 227. SocketProtocol= Akzeptiert entweder udplite oder sctp. Das Socket wird das UDP-Lite-(IPPROTO_UDPLITE) bzw. SCP-Protokoll (IPPROTO_SCTP) verwenden. Hinzugefugt in Version 229. BindIPv6Only= Akzeptiert entweder default, both oder ipv6-only. Steuert die Socket-Option IPV6_V6ONLY (siehe ipv6(7) fur Details). Falls both, werden IPv6-gebundene Sockets sowohl uber IPv4 als auch IPv6 zugreifbar sein. Falls ipv6-only, werden sie nur uber IPv6 zugreifbar sein. Falls default (was, Uberraschung, die Vorgabe ist), wird die systemweite Voreinstellung, wie sie durch /proc/sys/net/ipv6/bindv6only gesteuert wird, die standardmassig wiederum ein Aquivalent 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 fur Datenstrom- und sequenzielle Paket-Sockets relevant. Siehe listen(2) fur Details. Standardmassig 4294967295. Beachten Sie, dass dieser Wert ohne Ruckmeldung durch den Sysctl >>net.core.somaxconn<< nach oben begrenzt wird, standardmassig 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) fur Details). Falls diese Option verwandt wird, wird eine implizite Abhangigkeit von dieser Socket-Unit auf die Netzwerkschnittellen-Gerate-Unit (siehe systemd.device(5)) erstellt. Beachten Sie, dass das Setzen dieses Parameters zur Erganzung zusatzlicher Abhangigkeiten zu der Unit fuhren konnte (siehe oben). SocketUser=, SocketGroup= Akzeptiert einen UNIX-Benutzer-/Gruppennamen. Wenn angegeben, gehoren alle AF_UNIX-Sockets und FIFO-Knoten im Dateisystem dem angegebenen Benutzer und der angegebenen Gruppe. Falls nicht gesetzt (die Vorgabe), gehoren die Knoten dem Benutzer/der Gruppe root (falls im Systemkontext ausgefuhrt) oder dem aufrufenden Benutzer/der aufrufenden Gruppe (falls im Benutzerkontext ausgefuhrt). Falls nur ein Benutzer aber keine Gruppe angegeben ist, dann wird die Gruppe von der Standardgruppe des Benutzers abgeleitet. Hinzugefugt in Version 214. SocketMode= Falls auf einem Dateisystem-Socket oder FIFO auf Anfragen gewartet wird, gibt diese Option den Dateisystemzugriffsmodus bei der Erzeugung des Dateiknotens an. Akzeptiert einen Zugriffsmodus in oktaler Notation. Standardmassig 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. Standardmassig 0755. Accept= Akzeptiert ein logisches Argument. Falls yes, wird fur jede eingehende Verbindung eine Dienste-Instanz gestartet und nur der Verbindungs-Socket ubergeben. Falls no, werden alle auf Anfragen wartende Sockets selbst an die startende Dienst-Unit ubergeben und nur eine Dienste-Unit wird fur alle Verbindungen gestartet (siehe auch oben). Dieser Wert wird fur Datagram-Sockets und FIFOs ignoriert, wo eine einzelne Dienste-Unit bedingungslos allen eingehenden Verkehr bearbeitet. Standardmassig no. Zur Erhohung der Leistung wird empfohlen, neue Daemons nur so zu schreiben, dass sie fur 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 hauptsachlich nutzlich, um Daemons, die fur die Verwendung mit inetd(8) entwickelt wurden, zu erlauben, unverandert mit Systemd-Socket-Aktivierung zu funktionieren. Beachten Sie, dass abhangig von dieser Einstellung die von Units mit diesem Typ aktivierten Dienste entweder regulare Dienste (im Falle von Accept=no) oder Instanzen von vorlagenbasierten Diensten (im Falle von Accept=yes) sind. Siehe den obigen Abschnitt Beschreibung fur eine detailliertere Diskussion der Benennungsregeln fur ausgeloste Dienste. Fur 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. Fur SOCK_RAW ist der Port das IP-Protokoll. Es wird empfohlen, fur 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 wahr, wird die angegebene besondere Datei im Lese-/Schreibmodus geoffnet, falls falsch, im nur-Lesemodus. Standardmassig falsch. Hinzugefugt 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 ausgeloste Dienst beendet hat. Damit werden samtliche anhangige Daten rausgeschrieben und anhangende eingehende Verbindungen abgelehnt. Falls >>no<<, werden die Puffer des Sockets nicht bereinigt, wodurch dem Dienst ermoglicht wird, samtliche anhangende Verbindungen nach dem Neustart zu bedienen, was das normalerweise erwartete Verhalten darstellt. Standardmassig no. Hinzugefugt in Version 247. MaxConnections= Die maximale Anzahl an Verbindungen, fur die gleichzeitig Dienste-Instanzen ausgefuhrt 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. Standardmassig 64. MaxConnectionsPerSource= Die maximale Anzahl an Verbindungen fur einen Dienst pro Quell-IP-Adresse. Dies ist sehr ahnlich zu der Anweisung MaxConnections= oben. Standardmassig deaktiviert. Hinzugefugt in Version 232. KeepAlive= Akzeptiert ein logisches Argument. Falls wahr, wird der TCP/IP-Stack eine Aufrechterhaltungsnachricht nach 2 Stunden (abhangig von der Konfiguration von /proc/sys/net/ipv4/tcp_keepalive_time) fur alle TCP-Datenstrome, die auf diesem Socket akzeptiert sind, senden. Dies steuert die Socket-Option SO_KEEPALIVE (siehe socket(7) und die Dokumentation TCP-Aufrechterhaltungs-HOWTO[2] fur Details). Standardmassig 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] fur Details). Standardwert ist 7200 Sekunden (2 Stunden). Hinzugefugt 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] fur Details). Standardwert ist 75 Sekunden. Hinzugefugt in Version 216. KeepAliveProbes= Akzeptiert eine Ganzzahl als Argument. Sie ist die Anzahl von nicht bestatigten Testern, die gesandt werden mussen, 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] fur Details). Standardwert ist 9. Hinzugefugt 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)). Standardmassig false. Hinzugefugt in Version 216. Priority= Akzeptiert ein Ganzzahlargument, das die Prioritat steuert, mit der samtlicher Verkehr von diesem Socket gesandt wird. Dies steuert die Socket-Option SO_PRIORITY (siehe socket(7) fur 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 anfangliche ACK-Pakete ohne Daten ignorieren. Das Argument gibt die ungefahre Zeitdauer an, die der Kernel auf eingehende Daten warten sollte, bevor er auf das normale Verhalten der Berucksichtigung leerer ACK-Pakete zuruckfallen soll. Diese Option nutzt bei Protokollen, bei denen der Client Daten zuerst sendet (z.B. HTTP im Gegensatz zu SMTP), da der Serverprozess nicht unnotigerweise aufgeweckt werden wird, bevor er irgendetwas erledigen kann. Falls der Client auch die Option TCP_DEFER_ACCEPT verwendet, wird die Latenz der anfanglichen Verbindung auch reduziert, da der Kernel die Daten im abschliessenden Paket des Verbindungsaufbaus (dem dritten Paket der Dreiwege-Datenflusssteuerung) senden wird. Standardmassig deaktiviert. Hinzugefugt in Version 216. ReceiveBuffer=, SendBuffer= Akzeptiert ein Ganzzahlargument, das die Empfangs- bzw. Sendepuffergrosse des Sockets steuert. Dies steuert die Socket-Optionen SO_RCVBUF und SO_SNDBUF (siehe socket(7) fur Details). Die normalen Endungen K, M, G werden unterstutzt und zur Basis 1024 interpretiert. IPTOS= Akzeptiert ein Ganzzahlargument, das das IP-Feld >>Type-Of-Service<< fur von diesem Socket erstellte Pakete steuert. Dies steuert die Socket-Option IP_TOS (siehe ip(7) fur 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<< fur von diesem Socket erstellte Pakete steuert. Dies steuert die Socket-Option IP_TTL/IPV6_UNICAST_HOPS (siehe ip(7) und ipv6(7) fur 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) fur 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) fur Details. Hinzugefugt 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 fur eingehende bzw. ausgehende Verindungen auf dem Socket. Siehe Smack[3] fur Details. Hinzugefugt in Version 196. SELinuxContextFromNet= Akzeptiert ein logisches Argument. Falls wahr, wird Systemd versuchen, das fur den instanziierten Dienst verwandte SELinux-Label aus den vom Peer uber das Netzwerk ubergebenen Informationen herauszufinden. Beachten Sie, dass von den vom Peer ubergebenen Informationen nur die Sicherheitsstufe verwandt wird. Andere Anteile des ergebenen SELinux-Kontextes stammen entweder vom Zielprogramm, das effektiv vom Socket ausgelost wird, oder aus dem Wert der Option SELinuxContext=. Diese Konfigurationsoption ist nur anwendbar, wenn der aktivierte Dienst in einem einzelnen Socket-Dateideskriptor ubergeben wird, d.h. die Dienste-Instanzen, bei denen die Standardeingabe mit einem Socket verbunden ist oder Dienste, die durch genau eine Socket-Unit ausgelost werden. Beachten Sie auch, dass diese Option nur nutzlich ist, wenn eine MLS/MCS-SELinux-Richtlinie eingesetzt wird. Standardmassig >>false<<. Hinzugefugt in Version 217. PipeSize= Akzeptiert eine Grosse in Bytes. Steuert die Pipepuffergrosse der FIFOs, die in dieser Socket-Unit konfiguriert werden. Siehe fcntl(2) fur Details. Die normalen Endungen K, M, G werden unterstutzt 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 mussen. Siehe mq_setattr(3) fur Details. FreeBind= Akzeptiert einen logischen Wert. Steuert, ob der Socket an eine nichtlokale IP-Adresse gebunden werden kann. Dies ist nutzlich, 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 Robustheitsgrunden wird empfohlen, diese Option immer zu benutzen, wenn Sie ein Socket an eine bestimmte IP-Adresse binden. Standardmassig false. Transparent= Akzeptiert einen logischen Wert. Steuert die Socket-Option IP_TRANSPARENT/IPV6_TRANSPARENT. Standardmassig false. Broadcast= Akzeptiert einen logischen Wert. Dies steuert die Socket-Option SO_BROADCAST, die das Senden von Datagrammen von diesem Socket erlaubt. Standardmassig 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. Standardmassig 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. Standardmassig false. PassPacketInfo= Akzeptiert einen logischen Wert. Dies steuert die Socket-Optionen IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO oder PACKET_AUXDATA, die dem Empfang zusatzlicher, paketbezogener Metadaten auf den Sockets AF_INET, AF_INET6, AF_UNIX und AF_PACKET als Zusatznachrichten aktivieren. Standardmassig false. Hinzugefugt 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. Standardmassig off. Hinzugefugt in Version 247. TCPCongestion= Akzeptiert einen Zeichenkettenwert. Steuert den von diesem Socket verwandten TCP-Uberlastungsalgorithmus. Sollte entweder >>westwood<<, >>veno<<, >>cubic<<, >>lp<< oder jeder andere vom IP-Stack verfugbare Algorithmus sein. Diese Einstellung gilt nur fur Datenstrom-Sockets. ExecStartPre=, ExecStartPost= Akzeptiert eine oder mehrere Befehlszeilen, die ausgefuhrt 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 fur den Prozess folgen. Gemass des fur ExecStartPre= bei Dienste-Unit-Dateien verwandten Schematas konnen mehrere Befehlszeilen angegeben werden. ExecStopPre=, ExecStopPost= Zusatzliche Befehle, die ausgefuhrt werden, vor bzw. nachdem der auf Anfragen wartende Socket/FIFO geschlossen und entfernt wurde. Gemass des fur ExecStartPre= bei Dienste-Unit-Dateien verwandten Schematas konnen 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 Verzogerung dieser Zeitdauer mit SIGKILL beendet. (Siehe KillMode= in systemd.kill(5).) Akzeptiert einen einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie >>5min 20s<<. Durch Ubergabe von >>0<< wird die Zeituberschreitungslogik deaktiviert. Standardmassig 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 fur Sockets mit Accept=no erlaubt. Standardmassig wird der Dienst verwandt, der den gleichen Namen wie das Socket tragt (mit entfernter Endung). Meistens sollte es nicht notwendig sein, diese Option zu verwenden. Beachten Sie, dass Setzen dieses Parameters zur Hinzunahme zusatzlicher Abhangigkeiten fuhren 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 fur 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 konnten, nachdem die Socket-Unit beendet wurde und es sollte weiterhin moglich sein, mit ihnen uber den Dateisystemknoten zu kommunizieren. Standardmassig aus. Hinzugefugt 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 fur die Socket-Unit konfiguriert sein. Verwenden Sie diese Option, um einen oder mehrere Symlink-Aliasnamen fur einen Socket zu verwalten und ihren Lebenszyklus zu verknupfen. Beachten Sie, dass es fur die Socket-Unit nicht als fatal betrachtet wird, wenn die Erstellung eines Symlinks fehlschlagt und die Socket-Unit weiterhin starten konnte. Falls eine leere Zeichenkette zugewiesen wird, wird die Liste der Pfade zuruckgesetzt. Standardmassig eine leere Liste. Hinzugefugt 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 ubergeben werden. Dienste konnen den Aufruf sd_listen_fds_with_names(3) verwenden, um den konfigurierten Namen fur die empfangenen Dateideskriptoren zu erlangen. Die Namen durfen jedes ASCII-Zeichen enthalten, allerdings keine Steuerzeichen und >>:<<, und durfen hochstens 255 Zeichen lang sein. Falls diese Einstellung nicht verwandt wird, ist die Vorgabe fur Dateideskriptoren der Name der Socket-Unit, einschliesslich ihrer Endung .socket. Hinzugefugt in Version 227. TriggerLimitIntervalSec=, TriggerLimitBurst= Konfiguriert eine Begrenzung, wie oft diese Socket-Unit innerhalb eines bestimmten Zeitintervalls aktiviert werden darf. Die Lange 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) fur Details uber 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 fur Sockets mit Accept=yes (daher werden standardmassig 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 Ausloseratenbegrenzung zu deaktivieren. Falls diese Begrenzung erreicht wird, wird die Socket-Unit in den Fehlerzustandmodus gebracht und Verbindungen zu ihr sind nicht mehr moglich, 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 temporare Verlangsamung implementiert, falls eine Socket-Unit mit eingehendem Verkehr geflutet wird, im Gegenteil zum dauerhaften Fehlzustand, zu dem TriggerLimitIntervalSec=/TriggerLimitBurst= fuhrt. Hinzugefugt in Version 230. PollLimitIntervalSec=, PollLimitBurst= Konfiguriert eine Beschrankung, wie oft Polling-Ereignisse fur den dieser Unit zugrundeliegenden Dateideskriptoren berucksichtigt werden. Dieses Paar von Einstellungen ist ahnlich TriggerLimitIntervalSec=/TriggerLimitBurst=, aber anstatt eine (fatale) Beschrankung auf die Aktivierungsfrequenz zu legen, wird eine (vorubergehende) Beschrankung 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-Beschrankung erreicht wird, wird Polling vorubergehend darauf deaktiviert, bis das festgelegte Fenster verstrichen ist. Die Polling-Beschrankung verlangsamt daher nach Erreichen die Verbindungsversuche, fuhrt aber anders als die Auslosebeschrankung nicht zu einem dauerhaften Fehlschlag. Es ist der empfohlene Mechanismus, um mit DoS-Versuchen mittels Paket-Flutung umzugehen. Die Polling-Beschrankung wird pro Dateideskriptor, bei dem auf Anfragen gewartet wird, durchgesetzt, anders als bei der Auslosebeschrankung, die fur die gesamte Socket-Unit durchgesetzt wird. Diese Beschrankung ist fur Socket-Units wichtig, die auf mehreren Dateideskriptoren auf Anfragen warten (d.h. die uber mehrere Absatze ListenXYZ= verfugen). Diese Einstellungen betragen standardmassig 150 (im Falle von Accept=yes=) und (andernfalls) 15 Polling-Ereignisse pro 2s. Dies ist betrachtlich niedriger als die Vorgabewerte fur die Auslosungsbeschrankung (siehe oben) und bedeutet, dass die Polling-Beschrankung typischerweise sicherstellen soll, dass die Auslosebeschrankung niemals erreicht wird, ausser eine von ihnen ist rekonfiguriert oder deaktiviert. Hinzugefugt in Version 255. Lesen Sie systemd.unit(5), systemd.exec(5) und systemd.kill(5) fur 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) Fur eine ausfuhrlichere Beschreibung siehe die Serie >>Systemd fur 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 UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD.SOCKET(5)