Script runit de Sidekiq demasiado frágil: **discourse:www-data** **+ forzado** **-L log/sidekiq.log** **causa fallo de 1 segundo**

Soporte
3

Hola: permítame reiterar esto estrictamente basándome en los hechos en tiempo de ejecución del contenedor Docker oficial.

Lo que estoy viendo en el contenedor en ejecución (hechos)

Esta es una instalación oficial de Docker con runit (flujo de trabajo estándar del lanzador /var/discourse; sin reconstrucción justo antes del incidente). Dentro del contenedor:

  1. Existe un servicio Sidekiq de runit y es el que está siendo supervisado
ls -l /etc/service/sidekiq/run
sv status sidekiq

Salida durante el incidente:

down: sidekiq: 1s, normally up, want up
  1. El inicio manual de Sidekiq funciona
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

Esto permanece activo, se conecta a Redis y procesa trabajos.

  1. Solo parchear /etc/service/sidekiq/run (sin reconstruir) soluciona el bucle de fallos inmediatamente Reemplacé /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'

Después de eso:

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

Por lo tanto, Sidekiq no se está iniciando a través del maestro de Unicorn en esta imagen; es un servicio runit cuyo script de tiempo de ejecución puede entrar en bucle de fallos.

Por qué es posible que no vea el código exacto en

discourse_docker

Estoy de acuerdo en que el texto literal puede no estar en el repositorio porque /etc/service/sidekiq/run es un artefacto de tiempo de ejecución generado/inyectado durante la compilación/arranque de la imagen, no necesariamente un archivo literal en discourse_docker. Pero es el servicio supervisado activo en esta imagen oficial, como se demostró anteriormente.

Lo que desencadenó la fragilidad (hechos + inferencia mínima)

  • También observamos fallos diarios de logrotate debido a los permisos estándar de Debian: /var/log = root:adm 0775, por lo que logrotate se negó a rotar hasta que se agregó su root adm global.
  • Cuando logrotate fallaba, recreaba archivos en /shared/log/rails/, incluido sidekiq.log.
  • El script runit predeterminado en esta imagen usaba discourse:www-data y forzaba -L log/sidekiq.log en /shared/log, lo que hace que Sidekiq sea muy sensible a la deriva de permisos del volumen compartido y puede causar una salida inmediata antes de obtener registros útiles.

Solicitud / propuesta

Dado lo anterior, ¿podríamos considerar reforzar el servicio Sidekiq predeterminado de Docker/runit?

Valores predeterminados sugeridos:

  • ejecutar como discourse:discourse (coincide con la propiedad típica dentro del contenedor),
  • iniciar a través de bundle exec sidekiq -C config/sidekiq.yml,
  • evitar forzar un -L log/sidekiq.log compartido (o hacerlo resistente).

Esto evitaría el bucle de fallos silencioso down: 1s que detiene todos los trabajos en segundo plano/IA.

Estaré encantado de probar cualquier rama/commit al que me señale.