table of contents
- bookworm 4.18.1-1
- bookworm-backports 4.21.0-2~bpo12+1
- testing 4.21.0-2
- unstable 4.22.0-1
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 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:
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:
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) und systemd.kill(5) dokumentiert. Die für den Abschnitt »[Socket]« in Socket-Units speziellen Optionen sind die folgenden:
ListenStream=, ListenDatagram=, ListenSequentialPacket=
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.
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=
ListenSpecial=
ListenNetlink=
ListenMessageQueue=
ListenUSBFunction=
Hinzugefügt in Version 227.
SocketProtocol=
Hinzugefügt in Version 229.
BindIPv6Only=
Backlog=
BindToDevice=
SocketUser=, SocketGroup=
Hinzugefügt in Version 214.
SocketMode=
DirectoryMode=
Accept=
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 SOCK_RAW ist der Port das IP-Protokoll.
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=
Hinzugefügt in Version 227.
FlushPending=
Hinzugefügt in Version 247.
MaxConnections=
MaxConnectionsPerSource=
Hinzugefügt in Version 232.
KeepAlive=
KeepAliveTimeSec=
Hinzugefügt in Version 216.
KeepAliveIntervalSec=
Hinzugefügt in Version 216.
KeepAliveProbes=
Hinzugefügt in Version 216.
NoDelay=
Hinzugefügt in Version 216.
Priority=
DeferAcceptSec=
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=
IPTOS=
IPTTL=
Mark=
ReusePort=
Hinzugefügt in Version 206.
SmackLabel=, SmackLabelIPIn=, SmackLabelIPOut=
Hinzugefügt in Version 196.
SELinuxContextFromNet=
Hinzugefügt in Version 217.
PipeSize=
MessageQueueMaxMessages=, MessageQueueMessageSize=
FreeBind=
Transparent=
Broadcast=
PassCredentials=
PassSecurity=
PassPacketInfo=
Hinzugefügt in Version 246.
Timestamping=
Hinzugefügt in Version 247.
TCPCongestion=
ExecStartPre=, ExecStartPost=
ExecStopPre=, ExecStopPost=
TimeoutSec=
Service=
RemoveOnStop=
Hinzugefügt in Version 214.
Symlinks=
Hinzugefügt in Version 214.
FileDescriptorName=
Hinzugefügt in Version 227.
TriggerLimitIntervalSec=, TriggerLimitBurst=
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=
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.
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
- 2.
- TCP-Aufrechterhaltungs-HOWTO
- 3.
- Smack
- 4.
- Socket-Aktivierung
- 5.
- Socket-Aktivierung, Teil II
- 6.
- Inetd-Dienste-Konvertierung
- 7.
- Socket-aktivierte Internet-Dienste und Betriebssystem-Container
Ü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.
systemd 255 |