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

Error
1

Hola equipo:

Informo de un modo de fallo en la configuración oficial de Docker/runit que puede terminar silenciosamente con Sidekiq (y por lo tanto con los trabajos de IA/fondo) sin ninguna reconstrucción o actualización.

Entorno

  • Instalación oficial de Discourse Docker (contenedor estándar + servicios runit).
  • Sin reconstrucción/actualización justo antes de que comenzara el problema.
  • El complemento Discourse AI está habilitado, pero la IA dejó de responder.

Síntomas

  • La IA parece habilitada en la interfaz de administración, pero no aparecen respuestas de IA.
  • Los trabajos en segundo plano (IA/incrustaciones/respuesta automática) parecen estar atascados.
  • sv status sidekiq muestra que Sidekiq muere repetidamente justo después de iniciarse:
down: sidekiq: 1s, normally up, want up
  • Iniciar Sidekiq manualmente funciona bien, por lo que la aplicación en sí está bien:
bundle exec sidekiq -C config/sidekiq.yml
# permanece activo, se conecta a Redis, procesa trabajos

Lo que encontramos

El script runit predeterminado era:

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

Dos puntos de fragilidad:

  1. Grupo principal www-data En mi contenedor, las rutas típicas de escritura son propiedad de discourse:discourse. Cualquier deriva en tmp/pids o rutas compartidas puede hacer que Sidekiq salga durante el arranque cuando se ejecuta bajo www-data, aunque el inicio manual como discourse funcione.
  2. Escritura forzada -L log/sidekiq.log en registros compartidos La ruta del registro es un enlace simbólico a /shared/log/rails/sidekiq.log. Si ese archivo/directorio se recrea con diferente propiedad/permisos, Sidekiq puede salir inmediatamente antes de producir registros útiles.

Desencadenante relacionado: logrotate fallando diariamente

Por separado, logrotate fallaba todos los días con:

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

La causa fueron los permisos estándar de Debian/Ubuntu:

  • /var/log es root:adm con 0775 (escritura de grupo).
  • logrotate se niega a rotar a menos que se establezca una directiva su global. Este es el comportamiento esperado aguas arriba.

En el momento en que el trabajo diario de logrotate falló, también recreó archivos en /shared/log/rails/ (incluido sidekiq.log), lo que probablemente interactuó con el registro forzado -L y contribuyó al bucle de “fallo de 1s” de Sidekiq.

Solución (no se necesita reconstrucción)

  1. Arreglar logrotate para que deje de tocar los registros compartidos en un estado de fallo Agregar una directiva su global:
# /etc/logrotate.conf (parte superior)
su root adm

Después de eso, logrotate -v sale con 0 y ya no informa de permisos de directorio padre inseguros.

  1. Reemplazar el script runit de Sidekiq con una predeterminada más robusta Cambiar a discourse:discourse y el sidekiq.yml estándar, y no forzar -L log/sidekiq.log, hace que Sidekiq sea estable:
#!/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 esto:

  • sv status sidekiq permanece en ejecución:
  • Los trabajos de IA/fondo se reanudan.

Solicitud / sugerencia

¿Podríamos considerar hacer que el servicio Sidekiq oficial de Docker/runit sea más robusto por defecto?

Por ejemplo:

  • Ejecutar Sidekiq bajo discourse:discourse (coincidiendo con la propiedad típica dentro del contenedor).
  • Preferir bundle exec sidekiq -C config/sidekiq.yml.
  • Evitar forzar un archivo de registro compartido a través de -L log/sidekiq.log, o hacerlo resistente a la deriva de permisos de logrotate/volumen compartido.

Incluso una nota de documentación (“si Sidekiq muestra down: 1s pero el inicio manual funciona, verifique /etc/service/sidekiq/run y evite el registro compartido forzado”) ayudaría mucho a los autoalojados.

Estoy a su disposición para proporcionar más registros si es necesario. ¡Gracias!