Nginx startet in einer Crash-Schleife nach Container-Neustart: Basis-Image enthält brotli_static in discourse.conf, lädt das Modul aber nie (unbekannte Direktive)

Beitragen Fehler
1

Zusammenfassung
Nach einem routinemäßigen Neustart des Containers (Host-Neustart / docker restart) schlägt der Start von nginx im app-Container mit folgender Fehlermeldung fehl:

nginx: [emerg] unknown directive "brotli_static" in /etc/nginx/conf.d/discourse.conf:172

Dadurch ist die gesamte Website offline (kein Fallback – nginx bindet nie an Port 80/443), bis manuell behoben wird.

Umgebung

  • Basis-Image: discourse/base:2.0.20260812-0036
  • nginx: 1.26.3-3+deb13u7 (Debian 13/trixie-Paket, nicht selbst kompiliert)
  • libnginx-mod-http-brotli-static/-filter 1.0.0~rc-6 sind installiert, und die Symlinks in /etc/nginx/mods-enabled/*.conf (mit den korrekten load_module-Zeilen) existieren und verweisen auf gültige .so-Dateien.

Ursache
/etc/nginx/nginx.conf (Eigentum des Pakets nginx-common, unverändert) enthält keine include /etc/nginx/modules-enabled/*.conf;-Direktive, sodass die installierten Brotli-Module nie geladen werden – während discourse.conf (generiert durch die Discourse-Vorlagen) weiterhin brotli_static on; ausgibt und davon ausgeht, dass diese geladen sind.

Warum der Fehler nicht sofort auftritt
Die Konfiguration wird nur neu geparst, wenn nginx tatsächlich (neu) startet. Ein frisch neu gebauter Container kann problemlos Tage oder Wochen laufen, bis etwas nginx neu startet (Host-Neustart, docker restart, OOM usw.). Zu diesem Zeitpunkt beginnt er stillschweigend in eine Crash-Schleife zu geraten (~1×/Sekunde), ohne automatische Wiederherstellung.

Workaround
include /etc/nginx/modules-enabled/*.conf; als erste Zeile in /etc/nginx/nginx.conf hinzufügen (Hauptkontext, vor events {}). Bestätigt, dass dies den Erfolg von nginx -t und den normalen Betrieb wiederherstellt.

Anfrage
Könnte das Basis-Image entweder (a) dieses Include in seine nginx.conf hinzufügen, oder (b) brotli_static/brotli aus der mitgelieferten discourse.conf-Vorlage entfernen, falls der Build des Distro-nginx-Pakets Brotli-Support nicht mehr standardmäßig bündelt?

2 „Gefällt mir“
2

Korrektur meines eigenen Berichts: Das Basisimage ist in Ordnung. Die Ursache lag lokal in unserer Installation.

Was tatsächlich passiert ist

Ein lokaler Cron-Job auf unserem Host kopiert veraltete, manuell gepflegte nginx-Konfigurationsdateien in den laufenden Container. Eine davon stammt aus der Zeit vor include /etc/nginx/modules-enabled/*.conf;, eine andere setzt immer noch brotli_static on;. Zusammen erzeugen sie die Meldung unknown directive "brotli_static", und nginx verweigert den Start.

Warum ich es falsch diagnostiziert habe

Ich habe /etc/nginx/nginx.conf im laufenden Container überprüft und festgestellt, dass der modules-enabled-Include fehlt. Diese Datei war bereits lokal überschrieben worden, sodass der laufende Container nie widergespiegelt hat, was Discourse tatsächlich generiert. Die Überprüfung des gebauten Images macht es jedoch offensichtlich. Der Include ist vorhanden:

docker create --name check local_discourse/app
docker cp check:/etc/nginx/nginx.conf ./
docker rm check

Warum das Problem erst verzögert auftrat

Dieser Teil ist für andere vielleicht nützlich. Der Job endet mit nginx -s reload und verwirft dessen Ausgabe. Wenn die Konfiguration fehlerhaft ist, schlägt der Reload stillschweigend fehl, und der laufende nginx bedient weiterhin Anfragen aus seiner bereits geladenen Konfiguration. Alles sieht gesund aus. Der Fehler wird erst beim nächsten eigentlichen nginx-Start sichtbar, was bei uns ein unbeaufsichtigter Kernel-Upgrade war, der den Host Tage später neu startete.

Wenn also ein Discourse-Container Traffic sauber bedient hat und dann bei einem unbeteiligten Neustart abstürzt, prüft, ob etwas in der Zwischenzeit seine nginx-Konfiguration überschrieben hat.

Entschuldigung für die Verwirrung, und danke an alle, die sich die Zeit genommen haben, sich das anzusehen.

1 „Gefällt mir“