Script runit do Sidekiq muito frágil: **discourse:www-data** **+ forçado** **-L log/sidekiq.log** **causa falha de 1 segundo**

Suporte
3

Olá — deixe-me reformular isso estritamente com base nos fatos de tempo de execução do contêiner Docker oficial.

O que estou vendo no contêiner em execução (fatos)

Esta é uma instalação Docker oficial com runit (fluxo de trabalho padrão do lançador /var/discourse; sem reconstrução imediatamente antes do incidente). Dentro do contêiner:

  1. Um serviço Sidekiq do runit existe e é o que está sendo supervisionado
ls -l /etc/service/sidekiq/run
sv status sidekiq

Saída durante o incidente:

down: sidekiq: 1s, normally up, want up
  1. A inicialização manual do Sidekiq funciona
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

Isso permanece ativo, conecta-se ao Redis e processa trabalhos.

  1. Apenas a aplicação de patch em /etc/service/sidekiq/run (sem reconstrução) corrige o loop de falha imediatamente Substituí /etc/service/sidekiq/run por:
#!/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'

Depois disso:

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

Portanto, o Sidekiq não está sendo iniciado via mestre Unicorn nesta imagem; é um serviço runit cujo script de tempo de execução pode entrar em loop de falha.

Por que você pode não ver o código exato em

discourse_docker

Concordo que o texto literal pode não estar no repositório porque /etc/service/sidekiq/run é um artefato de tempo de execução gerado/injetado durante a construção/inicialização da imagem, não necessariamente um arquivo literal em discourse_docker. Mas é o serviço supervisionado ativo nesta imagem oficial, como mostrado acima.

O que desencadeou a fragilidade (fatos + inferência mínima)

  • Também observamos falhas diárias do logrotate devido a permissões padrão do Debian: /var/log = root:adm 0775, então o logrotate recusou a rotação até adicionar global su root adm.
  • Quando o logrotate falhava, ele recriava arquivos em /shared/log/rails/, incluindo sidekiq.log.
  • O script runit padrão nesta imagem usava discourse:www-data e forçava -L log/sidekiq.log para /shared/log, o que torna o Sidekiq muito sensível à deriva de permissões de volume compartilhado e pode causar uma saída imediata antes de logs úteis.

Solicitação / proposta

Dado o acima, poderíamos considerar reforçar o serviço Sidekiq padrão do Docker/runit?

Padrões sugeridos:

  • executar como discourse:discourse (corresponde à propriedade típica dentro do contêiner),
  • iniciar via bundle exec sidekiq -C config/sidekiq.yml,
  • evitar forçar um compartilhamento -L log/sidekiq.log (ou torná-lo resiliente).

Isso evitaria o loop de falha silencioso down: 1s que interrompe todos os trabalhos em segundo plano/IA.

Ficarei feliz em testar qualquer branch/commit que você me aponte.