name: nullfeld-mariadb-socket-bind-fix
description: "MariaDB *:3306-Bind auf nullfeld live gefixt (2026-08-13) — Root Cause war mariadb.socket (Systemd-Socket-Aktivierung), nicht die App-Config; Override-Muster für künftige ähnliche Fälle"
metadata:
node_type: memory
type: project

Der seit [[crumbquestions-v0-crumb-bridge]]/deployment_checklist.rs (2026-08-11) dokumentierte Fund — MariaDB auf nullfeld bindet an *:3306 statt 127.0.0.1 — ist live behoben, nicht nur umbenannt.

Root Cause war überraschend: /etc/mysql/mariadb.conf.d/50-server.cnf hatte die ganze Zeit korrekt bind-address = 127.0.0.1 — MariaDB selbst bestätigte das per SHOW VARIABLES LIKE 'bind_address'. Die tatsächliche Ursache war mariadb.socket (Debian nutzt Systemd-Socket-Aktivierung für MariaDB): die Unit-Datei hat ListenStream=3306 ohne Adresse, wodurch Systemd den Port auf alle Interfaces bindet, bevor mariadbd überhaupt startet — die App-Config war die ganze Zeit korrekt, aber irrelevant.

Fix: /etc/systemd/system/mariadb.socket.d/override.conf:

[Socket]
ListenStream=
ListenStream=@mariadb
ListenStream=/run/mysqld/mysqld.sock
ListenStream=127.0.0.1:3306

Die leere ListenStream= zuerst ist zwingend nötig — sonst addiert der Override-Mechanismus nur zur bestehenden Liste, statt sie zu ersetzen. Danach daemon-reload.

Reihenfolge beim Neustart war der einzige Stolperstein: systemctl restart mariadb.socket schlägt fehl, solange mariadb.service noch läuft ("Socket service mariadb.service already active, refusing") — kein Schaden entstanden (alter Prozess lief unverändert weiter), aber die richtige Reihenfolge ist: stop mariadb.service → restart mariadb.socket → start mariadb.service.

Verifiziert: ss -tlnp danach 127.0.0.1:3306 statt *:3306. mysql SELECT 1 und der App-Health-Check (GET /health der laufenden Crumbforest-Instanz) blieben während des gesamten Eingriffs erreichbar — kein Ausfall.

In CrumbQuestions_v0 dokumentiert: deployment_checklist.rss Fail-Eintrag auf Pass gehoben, mit dem echten Fix als Evidence, Test in zwei benannte Tests aufgeteilt (Fix bestätigt vs. der zweite bekannte Fail — fehlende NGINX-Security-Header — bleibt offen).

Warum relevant für ähnliche Fälle: wenn eine Bind-Adresse in einer App-Config korrekt aussieht, aber ss -tlnp trotzdem eine offene Bindung zeigt, bei Debian/Systemd-verwalteten Diensten IMMER prüfen, ob ein <dienst>.socket-Unit mit eigenem ListenStream= existiert — das gewinnt gegen die App-eigene Config, weil Systemd den Socket öffnet, bevor der Dienst überhaupt startet. LISTEN-Zeile in ss -tlnp, die sowohl den Dienst-Prozess als auch systemd (pid=1) als Owner zeigt, ist der Hinweis auf Socket-Aktivierung.

Verwandt: [[nullfeld-qdrant-ollama-loopback-bind]] (gleicher nullfeld-Kontext, gleiches "wo bindet was wirklich"-Muster, aber dort war die App-Config selbst die Quelle — hier war es ausdrücklich nicht die App-Config).