systemd Socket Activation: Dienste erst bei Bedarf starten

1. Wie Socket Activation funktioniert

Das Grundprinzip von Socket Activation ist keine neue Erfindung von systemd, es ist eine moderne Umsetzung eines Konzepts, das bereits im klassischen inetd-Daemon der frühen Unix-Systeme existierte: Statt dass jeder Dienst seinen eigenen Netzwerk-Socket selbst öffnet und dauerhaft darauf lauscht, übernimmt eine zentrale Instanz, in diesem Fall systemd selbst, das Öffnen und Offenhalten des Sockets.

Trifft eine eingehende Verbindung auf diesem Socket ein, prüft systemd, ob der zugehörige Dienst bereits läuft. Ist das nicht der Fall, startet systemd den Dienst in genau diesem Moment und übergibt ihm den bereits offenen Socket als vorbereiteten File Descriptor, statt dass der Dienst selbst erst noch einen neuen Socket anlegen und binden müsste. Für den anfragenden Client ist dieser gesamte Vorgang unsichtbar, die Verbindung wird lediglich für den Bruchteil einer Sekunde verzögert bearbeitet.

2. .socket-Unit-Dateien: Grundlegender Aufbau

Eine Socket Unit definiert, worauf systemd lauschen soll, über die Direktive ListenStream= für TCP-Sockets oder Unix-Domain-Sockets, beziehungsweise ListenDatagram= für UDP. Die Angabe kann eine reine Portnummer sein, eine Kombination aus Adresse und Port, oder ein absoluter Pfad für einen lokalen Unix-Socket, was für die Kommunikation zwischen Prozessen auf derselben Maschine oft die performantere Wahl gegenüber TCP über Loopback ist.

Der Abschnitt [Install] mit WantedBy=sockets.target sorgt dafür, dass die Socket Unit beim Boot tatsächlich aktiviert wird. Wichtig ist die Unterscheidung: Aktiviert wird der Socket, nicht der Dienst selbst, der zugehörige Dienst bleibt zu diesem Zeitpunkt bewusst inaktiv, bis die erste Verbindung eintrifft.

# /etc/systemd/system/php-worker.socket
[Unit]
Description=Socket für den PHP Hintergrunddienst

[Socket]
ListenStream=127.0.0.1:9501
Accept=no

[Install]
WantedBy=sockets.target

3. Verknüpfung zwischen Socket-Unit und Service-Unit

Standardmäßig verknüpft systemd eine Socket Unit automatisch mit einer gleichnamigen Service Unit, sofern der Dateiname bis auf die Endung identisch ist, also php-worker.socket mit php-worker.service. Diese implizite Namenskonvention deckt den überwiegenden Teil der Anwendungsfälle bereits ab, ohne dass eine explizite Verknüpfung notwendig wäre.

Für Fälle, in denen ein abweichender Servicename gewünscht ist, oder in denen mehrere Sockets denselben Dienst aktivieren sollen, erlaubt die Direktive Sockets= in der Service Unit eine explizite Zuordnung. Diese Flexibilität ist besonders nützlich, wenn ein Dienst sowohl über einen TCP-Socket für externe Anfragen als auch über einen Unix-Socket für interne Kommunikation erreichbar sein soll.

# /etc/systemd/system/php-worker.service
[Unit]
Description=PHP Hintergrunddienst für Bild Konvertierung
Requires=php-worker.socket

[Service]
ExecStart=/usr/bin/php /opt/mironsoft/php-worker/worker.php
Sockets=php-worker.socket
StandardOutput=journal

4. Vorteile: schnellerer Boot und Lazy-Start

Der offensichtlichste Vorteil von Socket Activation ist ein schnellerer Boot: Statt beim Systemstart auf die vollständige Initialisierung jedes einzelnen Dienstes zu warten, öffnet systemd lediglich die zugehörigen Sockets, ein Vorgang, der praktisch verzögerungsfrei abläuft. Der eigentliche, potenziell langsame Startvorgang der Anwendung selbst verschiebt sich auf den Moment der ersten tatsächlichen Nutzung.

Ein weiterer, oft unterschätzter Vorteil ist die implizite Parallelisierung: Weil mehrere Dienste beim Boot nur ihre Sockets öffnen müssen statt vollständig zu initialisieren, können deutlich mehr Dienste gleichzeitig gestartet werden, ohne dass Abhängigkeitsketten den Boot künstlich verlängern. Ein Dienst, der auf einen anderen über dessen Socket zugreift, muss nicht mehr warten, bis dieser andere Dienst vollständig hochgefahren ist, sondern lediglich, bis dessen Socket verfügbar ist.

5. Accept=yes gegenüber Accept=no

Die Direktive Accept= in der Socket Unit entscheidet über ein grundlegend unterschiedliches Verhalten. Bei Accept=no, dem für die meisten modernen Anwendungen empfohlenen Modus, übergibt systemd den Listening-Socket selbst an eine einzelne, dauerhaft laufende Instanz des Dienstes, die dann intern selbst mehrere gleichzeitige Verbindungen verwaltet, etwa über eine eigene Event-Loop.

Bei Accept=yes startet systemd dagegen für jede einzelne eingehende Verbindung eine komplett neue Instanz des Dienstes, ähnlich dem klassischen inetd-Verhalten. Das eignet sich für einfache, zustandslose Skripte, verursacht aber bei hoher Verbindungsrate einen erheblichen Prozessstart-Overhead, weshalb dieser Modus für Anwendungen mit nennenswertem Durchsatz meist ungeeignet ist und eher für seltene, einfache Anfragen infrage kommt.

6. Praxisbeispiel: Eigener PHP-Hintergrunddienst mit Socket Activation

Ein typischer Anwendungsfall ist ein PHP-Hintergrunddienst, der Bild-Konvertierungen für Produktbilder außerhalb des regulären Magento-Request-Zyklus übernimmt, aber nur selten aufgerufen wird und deshalb nicht permanent im Speicher gehalten werden muss. Mit Socket Activation bleibt der Dienst inaktiv, bis tatsächlich eine Konvertierungsanfrage über den Socket eintrifft, wodurch weder Arbeitsspeicher noch ein PHP-Interpreter-Prozess dauerhaft belegt werden.

Für PHP-Anwendungen ist die Extension sockets zusammen mit einer kleinen Hilfsfunktion notwendig, um den von systemd übergebenen File Descriptor korrekt zu übernehmen, statt selbst einen neuen Socket zu öffnen. Sobald der Worker den übergebenen Socket erfolgreich eingebunden hat, verhält er sich für nachfolgende Verbindungen wie ein normaler, dauerhaft laufender Server.

#!/usr/bin/env php
<?php
declare(strict_types=1);

// worker.php: Von systemd per Socket Activation gestarteter PHP Worker
// Der erste von systemd uebergebene File Descriptor beginnt bei 3
$fd = 3;
$socket = socket_import_stream(fopen("php://fd/{$fd}", "r+"));

while (true) {
    $client = socket_accept($socket);
    if ($client === false) {
        continue;
    }
    // Konvertierungslogik für eingehende Anfragen
    socket_write($client, "OK\n");
    socket_close($client);
}

7. Umgang mit File Descriptors: LISTEN_FDS und LISTEN_PID

Damit ein per Socket Activation gestarteter Prozess erkennt, dass er einen bereits offenen Socket übernehmen soll statt selbst einen neuen zu öffnen, setzt systemd zwei Umgebungsvariablen: LISTEN_FDS gibt die Anzahl der übergebenen File Descriptors an, LISTEN_PID enthält die erwartete Prozess-ID, damit weitergereichte Kindprozesse die Variablen nicht versehentlich fälschlicherweise für sich selbst interpretieren.

Sprachen mit systemd-Bindings, etwa über die libsystemd-Bibliothek in C oder entsprechende Wrapper in Go und Python, kapseln diese Logik meist in einer Funktion namens sd_listen_fds, die die übergebenen File Descriptors validiert und als nutzbare Socket-Handles zurückgibt. Für PHP existiert keine offizielle Bibliotheksfunktion, weshalb die Übernahme, wie im vorherigen Beispiel gezeigt, manuell über die Standard-Extension sockets erfolgen muss.

8. Socket Activation mit Docker und Containern

Innerhalb eines Docker-Containers ist klassische Socket Activation kaum sinnvoll einsetzbar, weil Container in der Regel keinen eigenen systemd als PID 1 ausführen und das Container-Runtime-Modell ohnehin von dauerhaft laufenden Prozessen ausgeht, nicht von bedarfsgesteuertem Start. Ein Container, der beendet wird, sobald kein aktiver Prozess mehr läuft, würde dem Grundgedanken von Lazy-Start klassischer Socket Activation direkt widersprechen.

Sinnvoll bleibt Socket Activation dagegen auf dem Host-System selbst, außerhalb von Containern, etwa für eigene Hilfsdienste, die parallel zur Docker-basierten Magento-Infrastruktur laufen. Wer den Lazy-Start-Gedanken dennoch in einer Container-Umgebung nachbilden möchte, landet in der Praxis eher bei Kubernetes-nativen Mechanismen wie Scale-to-Zero, die konzeptionell ähnlich, aber technisch unabhängig von systemd realisiert sind.

9. Debugging und Troubleshooting bei Socket Activation

Der Befehl systemctl list-sockets zeigt alle aktiven Socket Units zusammen mit dem jeweils zugeordneten Dienst und dem aktuellen Aktivierungszustand, ein guter erster Anlaufpunkt, um zu prüfen, ob ein erwarteter Socket überhaupt geöffnet ist. Ergänzend zeigt systemctl status php-worker.socket Details zum Socket selbst, während systemctl status php-worker.service den tatsächlichen Zustand des dahinterliegenden Dienstes offenlegt.

Startet der Dienst nicht wie erwartet bei der ersten Verbindung, liefert journalctl -u php-worker.service die entsprechenden Fehlermeldungen. Ein häufiger Stolperstein ist eine fehlerhafte Namenskonvention zwischen Socket- und Service-Datei oder eine vergessene Sockets= Direktive bei abweichenden Dateinamen, was dazu führt, dass systemd den Socket zwar öffnet, aber beim Eintreffen einer Verbindung keinen passenden Dienst findet.

# Alle Socket Units und deren Aktivierungszustand anzeigen
systemctl list-sockets

# Logs des dahinterliegenden Dienstes bei Startproblemen pruefen
journalctl -u php-worker.service -e

10. Zusammenfassung

11. FAQ: Socket Activation