Sidekiq runit-Skript zu fragil: **discourse:www-data** **+ forced** **-L log/sidekiq.log** verursacht 1-sekündigen Absturz

Fehler
1

Hallo Team,

ich melde einen Fehler im offiziellen Docker/runit-Setup, der Sidekiq (und damit KI/Hintergrundjobs) stillschweigend beenden kann, ohne dass ein Rebuild oder Upgrade erforderlich ist.

Umgebung

  • Offizielle Discourse Docker-Installation (Standard-Container + runit-Dienste).
  • Kein Rebuild/Upgrade unmittelbar vor Auftreten des Problems.
  • Discourse AI-Plugin aktiviert, aber KI antwortet nicht mehr.

Symptome

  • KI wird in der Admin-UI als aktiviert angezeigt, aber es erscheinen keine KI-Antworten.
  • Hintergrundjobs (KI/Embeddings/Auto-Reply) scheinen festzustecken.
  • sv status sidekiq zeigt, dass Sidekiq unmittelbar nach dem Start wiederholt abstürzt:
down: sidekiq: 1s, normally up, want up
  • Manuelles Starten von Sidekiq funktioniert einwandfrei, die Anwendung selbst ist also in Ordnung:
bundle exec sidekiq -C config/sidekiq.yml
# bleibt aktiv, verbindet sich mit Redis, verarbeitet Jobs

Was wir herausgefunden haben

Das standardmäßige runit-Skript war:

exec chpst -u discourse:www-data \
  bash -lc 'cd /var/www/discourse && ... bundle exec sidekiq -e production -L log/sidekiq.log'

Zwei Schwachstellen:

  1. Primäre Gruppe www-data In meinem Container gehören typische beschreibbare Pfade discourse:discourse. Jede Abweichung bei tmp/pids oder gemeinsam genutzten Pfaden kann dazu führen, dass Sidekiq beim Booten unter www-data beendet wird, obwohl der manuelle Start als discourse funktioniert.
  2. Erzwungenes -L log/sidekiq.log Schreiben in gemeinsame Logs Der Protokollpfad ist ein Symlink nach /shared/log/rails/sidekiq.log. Wenn diese Datei/dieses Verzeichnis mit anderer Eigentümerschaft/Berechtigungen neu erstellt wird, kann Sidekiq sofort beendet werden, bevor nützliche Protokolle erstellt werden.

Zugehöriger Auslöser: logrotate schlägt täglich fehl

Unabhängig davon schlug logrotate jeden Tag fehl mit:

error: skipping "...log" because parent directory has insecure permissions
Set "su" directive in config file ...

Ursache waren Standard-Debian/Ubuntu-Berechtigungen:

  • /var/log gehört root:adm mit 0775 (gruppenschreibbar).
  • logrotate verweigert die Rotation, es sei denn, eine globale su-Direktive wird festgelegt. Dies ist das erwartete Upstream-Verhalten.

Genau in dem Moment, als der tägliche logrotate-Job fehlschlug, wurden auch Dateien unter /shared/log/rails/ (einschließlich sidekiq.log) neu erstellt, was wahrscheinlich mit der erzwungenen -L-Protokollierung interagierte und zur Sidekiq „1s Crash“-Schleife beitrug.

Fix (kein Rebuild erforderlich)

  1. Logrotate korrigieren, damit es aufhört, gemeinsame Logs in einem fehlerhaften Zustand zu berühren Eine globale su-Direktive hinzufügen:
# /etc/logrotate.conf (oben)
su root adm

Danach beendet sich logrotate -v mit 0 und meldet keine unsicheren übergeordneten Berechtigungen mehr.

  1. Sidekiq runit-Skript durch eine robustere Standardeinstellung ersetzen Der Wechsel zu discourse:discourse und der Standard sidekiq.yml und das Nicht-Erzwingen von -L log/sidekiq.log stabilisiert Sidekiq:
#!/bin/bash
exec 2>&1
cd /var/www/discourse

mkdir -p tmp/pids
chown discourse:discourse tmp/pids || true

exec chpst -u discourse:discourse \
  bash -lc 'cd /var/www/discourse && rm -f tmp/pids/sidekiq*.pid; exec bundle exec sidekiq -C config/sidekiq.yml'

Danach:

  • sv status sidekiq bleibt run.
  • KI/Hintergrundjobs werden wieder aufgenommen.

Anfrage / Vorschlag

Könnten wir in Betracht ziehen, den offiziellen Docker/runit Sidekiq-Dienst standardmäßig robuster zu gestalten?

Zum Beispiel:

  • Sidekiq unter discourse:discourse ausführen (entsprechend der typischen Eigentümerschaft innerhalb des Containers).
  • Bevorzugen Sie bundle exec sidekiq -C config/sidekiq.yml.
  • Vermeiden Sie das Erzwingen einer gemeinsamen Protokolldatei über -L log/sidekiq.log oder machen Sie diese widerstandsfähig gegen Berechtigungsabweichungen von logrotate/gemeinsam genutztem Volume.

Selbst ein Dokumentationshinweis („Wenn Sidekiq down: 1s anzeigt, aber der manuelle Start funktioniert, überprüfen Sie /etc/service/sidekiq/run und vermeiden Sie erzwungene gemeinsame Protokollierung“) würde Self-Hostern sehr helfen.

Gerne stelle ich weitere Protokolle zur Verfügung, falls erforderlich. Danke!