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 sidekiqmuestra 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:
- 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.
- 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/loges root:adm con 0775 (escritura de grupo).- logrotate se niega a rotar a menos que se establezca una directiva
suglobal. 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)
- Arreglar logrotate para que deje de tocar los registros compartidos en un estado de fallo Agregar una directiva
suglobal:
# /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.
- Reemplazar el script runit de Sidekiq con una predeterminada más robusta Cambiar a
discourse:discoursey elsidekiq.ymlestá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 sidekiqpermanece 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 delogrotate/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!
