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

Unterstützung
3

Hallo — ich formuliere dies streng basierend auf den Laufzeitfakten aus dem offiziellen Docker-Container neu.

Was ich im laufenden Container sehe (Fakten)

Dies ist eine offizielle Docker-Installation mit runit (Standard-Workflow des /var/discourse-Launchers; kein erneuter Build unmittelbar vor dem Vorfall). Im Container:

  1. Ein runit Sidekiq-Dienst existiert und wird überwacht
ls -l /etc/service/sidekiq/run
sv status sidekiq

Ausgabe während des Vorfalls:

down: sidekiq: 1s, normally up, want up
  1. Manueller Sidekiq-Start funktioniert
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

Dies bleibt aktiv, verbindet sich mit Redis und verarbeitet Jobs.

  1. **Das Patchen von nur /etc/service/sidekiq/run (ohne Rebuild) behebt die Crash-Schleife sofort Ersetzt wurde /etc/service/sidekiq/run durch:
#!/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
run: sidekiq: (pid <PID>) <SECONDS>s

Sidekiq wird also in diesem Image nicht über den Unicorn-Master gestartet; es ist ein runit-Dienst, dessen Laufzeitskript in einer Crash-Schleife stecken bleiben kann.

Warum Sie möglicherweise nicht den exakten Code in

discourse_docker sehen

Ich stimme zu, dass der wörtliche Text möglicherweise nicht im Repository enthalten ist, da /etc/service/sidekiq/run ein Laufzeitartefakt ist, das während des Image-Builds/-Boots generiert/injiziert wird, und nicht unbedingt eine wortgetreue Datei in discourse_docker. Aber es ist der aktive überwachte Dienst in diesem offiziellen Image, wie oben gezeigt.

Was die Fragilität ausgelöst hat (Fakten + minimale Schlussfolgerung)

  • Wir beobachteten auch tägliche logrotate-Fehler aufgrund von Standard-Debian-Berechtigungen: /var/log = root:adm 0775, sodass logrotate die Rotation verweigerte, bis global su root adm hinzugefügt wurde.
  • Als logrotate fehlschlug, erstellte es Dateien unter /shared/log/rails/ neu, einschließlich sidekiq.log.
  • Das Standard-runit-Skript in diesem Image verwendete discourse:www-data und zwang -L log/sidekiq.log in /shared/log, was Sidekiq sehr empfindlich gegenüber Berechtigungsabweichungen im Shared Volume macht und zu einem sofortigen Beenden führen kann, bevor nützliche Protokolle erstellt werden.

Anfrage / Vorschlag

Angesichts dessen, könnten wir in Erwägung ziehen, den standardmäßigen Docker/runit Sidekiq-Dienst zu härten?

Vorgeschlagene Standardwerte:

  • Ausführen als discourse:discourse (entspricht der typischen Eigentümerschaft innerhalb des Containers),
  • Start über bundle exec sidekiq -C config/sidekiq.yml,
  • Vermeidung des Erzwingens eines geteilten -L log/sidekiq.log (oder es resilient machen).

Dies würde die stille down: 1s Crash-Schleife verhindern, die alle Hintergrund-/KI-Jobs stoppt.

Gerne teste ich jeden Branch/Commit, auf den Sie mich verweisen.