Script runit Sidekiq trop fragile : **discourse:www-data** **+ forcé** **-L log/sidekiq.log** **provoque un crash d'une seconde**

Bug
1

Bonjour l’équipe,

je signale un mode de défaillance dans la configuration officielle Docker/runit qui peut tuer silencieusement Sidekiq (et donc les tâches d’IA/de fond) sans aucune reconstruction ni mise à jour.

Environnement

  • Installation officielle de Discourse Docker (conteneur standard + services runit).
  • Aucune reconstruction/mise à jour juste avant le début du problème.
  • Plugin Discourse AI activé, mais l’IA a cessé de répondre.

Symptômes

  • L’IA semble activée dans l’interface d’administration, mais aucune réponse de l’IA n’apparaît.
  • Les tâches de fond (IA/embeddings/réponse automatique) semblent bloquées.
  • sv status sidekiq montre que Sidekiq meurt de manière répétée juste après le démarrage :
down: sidekiq: 1s, normally up, want up
  • Le démarrage manuel de Sidekiq fonctionne bien, donc l’application elle-même est OK :
bundle exec sidekiq -C config/sidekiq.yml
# reste actif, se connecte à Redis, traite les tâches

Ce que nous avons trouvé

Le script runit par défaut était :

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

Deux points de fragilité :

  1. Groupe principal www-data Dans mon conteneur, les chemins inscriptibles typiques appartiennent à discourse:discourse. Tout décalage dans tmp/pids ou les chemins partagés peut faire que Sidekiq se termine au démarrage lorsqu’il est exécuté sous www-data, même si le démarrage manuel en tant que discourse fonctionne.
  2. Écriture forcée -L log/sidekiq.log dans les journaux partagés Le chemin du journal est un lien symbolique vers /shared/log/rails/sidekiq.log. Si ce fichier/répertoire est recréé avec des propriétaires/permissions différents, Sidekiq peut se terminer immédiatement avant de produire des journaux utiles.

Déclencheur connexe : logrotate échoue quotidiennement

Séparément, logrotate échouait tous les jours avec :

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

La cause était les permissions Debian/Ubuntu standard :

  • /var/log est root:adm avec 0775 (groupe inscriptible).
  • logrotate refuse la rotation à moins qu’une directive su globale ne soit définie. C’est le comportement attendu en amont.

Au moment où la tâche quotidienne de logrotate a échoué, elle a également recréé des fichiers sous /shared/log/rails/ (y compris sidekiq.log), ce qui a probablement interagi avec la journalisation forcée via -L et a contribué à la boucle de crash de Sidekiq « 1s ».

Correction (aucune reconstruction nécessaire)

  1. Corriger logrotate pour qu’il arrête de toucher aux journaux partagés dans un état d’échec Ajouter une directive su globale :
# /etc/logrotate.conf (en haut)
su root adm

Après cela, logrotate -v sort avec 0 et ne signale plus de permissions de répertoire parent non sécurisées.

  1. Remplacer le script runit de Sidekiq par un défaut plus robuste Passer à discourse:discourse et au sidekiq.yml standard, et ne pas forcer -L log/sidekiq.log, rend Sidekiq stable :
#!/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'

Après cela :

  • sv status sidekiq reste run :
  • Les tâches IA/de fond reprennent.

Demande / suggestion

Pourrions-nous envisager de rendre le service Sidekiq officiel Docker/runit plus robuste par défaut ?

Par exemple :

  • Exécuter Sidekiq sous discourse:discourse (correspondant à la propriété typique à l’intérieur du conteneur).
  • Préférer bundle exec sidekiq -C config/sidekiq.yml.
  • Éviter de forcer un fichier journal partagé via -L log/sidekiq.log, ou le rendre résilient à la dérive des permissions du volume partagé/logrotate.

Même une note de documentation (« si Sidekiq affiche down: 1s mais que le démarrage manuel fonctionne, vérifiez /etc/service/sidekiq/run et évitez la journalisation forcée partagée ») aiderait grandement les auto-hébergeurs.

Heureux de fournir plus de journaux si nécessaire. Merci !