Script runit di Sidekiq troppo fragile: **discourse:www-data** **+ forced** **-L log/sidekiq.log** **causa crash di 1 secondo**

Supporto
3

Ciao, permettimi di ribadire questo basandomi strettamente sui fatti di runtime dal container Docker ufficiale.

Cosa sto vedendo nel container in esecuzione (fatti)

Questa è un’installazione Docker ufficiale con runit (flusso di lavoro standard del lanciatore /var/discourse; nessuna ricostruzione immediatamente prima dell’incidente). All’interno del container:

  1. Esiste un servizio Sidekiq runit ed è quello supervisionato
ls -l /etc/service/sidekiq/run
sv status sidekiq

Output durante l’incidente:

down: sidekiq: 1s, normally up, want up
  1. L’avvio manuale di Sidekiq funziona
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

Questo rimane attivo, si connette a Redis ed elabora i job.

  1. La sola modifica di /etc/service/sidekiq/run (nessuna ricostruzione) risolve immediatamente il crash loop Sostituito /etc/service/sidekiq/run con:
#!/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'

Dopo di che:

sv status sidekiq
run: sidekiq: (pid <PID>) <SECONDS>s

Quindi Sidekiq non viene avviato tramite Unicorn master in questa immagine; è un servizio runit il cui script di runtime può entrare in un ciclo di crash.

Perché potresti non vedere il codice esatto in

discourse_docker

Concordo sul fatto che il testo letterale potrebbe non essere nel repository perché /etc/service/sidekiq/run è un artefatto di runtime generato/iniettato durante la build/boot dell’immagine, non necessariamente un file verbatim in discourse_docker. Ma è il servizio supervisionato attivo in questa immagine ufficiale, come mostrato sopra.

Cosa ha innescato la fragilità (fatti + minima inferenza)

  • Abbiamo anche osservato fallimenti giornalieri di logrotate a causa delle autorizzazioni Debian standard: /var/log = root:adm 0775, quindi logrotate ha rifiutato la rotazione fino all’aggiunta di global su root adm.
  • Quando logrotate falliva, ricreava file sotto /shared/log/rails/, incluso sidekiq.log.
  • Lo script runit predefinito in questa immagine utilizzava discourse:www-data e forzava -L log/sidekiq.log in /shared/log, il che rende Sidekiq molto sensibile alla deriva delle autorizzazioni del volume condiviso e può causare un’uscita immediata prima che vengano generati log utili.

Richiesta / proposta

Dato quanto sopra, potremmo considerare di rafforzare il servizio Sidekiq Docker/runit predefinito?

Impostazioni predefinite suggerite:

  • eseguire come discourse:discourse (corrisponde alla proprietà tipica all’interno del container),
  • avviare tramite bundle exec sidekiq -C config/sidekiq.yml,
  • evitare di forzare un -L log/sidekiq.log condiviso (o renderlo resiliente).

Ciò impedirebbe il ciclo di crash silenzioso down: 1s che interrompe tutti i job in background/AI.

Sono disponibile a testare qualsiasi branch/commit che mi indicherai.