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

Soutien
3

Bonjour, permettez-moi de reformuler ceci strictement sur la base des faits d’exécution à partir du conteneur Docker officiel.

Ce que je vois dans le conteneur en cours d’exécution (faits)

Il s’agit d’une installation Docker officielle avec runit (flux de travail standard du lanceur /var/discourse ; pas de reconstruction juste avant l’incident). À l’intérieur du conteneur :

  1. Un service Sidekiq runit existe et est celui qui est supervisé
ls -l /etc/service/sidekiq/run
sv status sidekiq

Sortie pendant l’incident :

down: sidekiq: 1s, normally up, want up
  1. Le démarrage manuel de Sidekiq fonctionne
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

Ceci reste actif, se connecte à Redis et traite les tâches.

  1. La correction (patching) uniquement de /etc/service/sidekiq/run (sans reconstruction) corrige immédiatement la boucle de crash Remplacement de /etc/service/sidekiq/run par :
#!/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
run: sidekiq: (pid <PID>) <SECONDS>s

Donc, Sidekiq n’est pas lancé via le maître Unicorn dans cette image ; c’est un service runit dont le script d’exécution peut entrer en boucle de crash.

Pourquoi vous pourriez ne pas voir le code exact dans

discourse_docker

Je suis d’accord, le texte littéral pourrait ne pas se trouver dans le dépôt car /etc/service/sidekiq/run est un artefact d’exécution généré/injecté pendant la construction/le démarrage de l’image, et non nécessairement un fichier verbatim dans discourse_docker. Mais c’est le service supervisé actif dans cette image officielle, comme montré ci-dessus.

Ce qui a déclenché la fragilité (faits + inférence minimale)

  • Nous avons également observé des échecs quotidiens de logrotate en raison des permissions Debian standard : /var/log = root:adm 0775, donc logrotate a refusé la rotation jusqu’à l’ajout de global su root adm.
  • Lorsque logrotate échouait, il recréait des fichiers sous /shared/log/rails/, y compris sidekiq.log.
  • Le script runit par défaut dans cette image utilisait discourse:www-data et forçait -L log/sidekiq.log dans /shared/log, ce qui rend Sidekiq très sensible à la dérive des permissions du volume partagé et peut provoquer une sortie immédiate avant que les journaux utiles ne soient écrits.

Demande / proposition

Compte tenu de ce qui précède, pourrions-nous envisager de renforcer le service Sidekiq Docker/runit par défaut ?

Défauts suggérés :

  • exécuter en tant que discourse:discourse (correspond à la propriété typique à l’intérieur du conteneur),
  • démarrer via bundle exec sidekiq -C config/sidekiq.yml,
  • éviter de forcer un -L log/sidekiq.log partagé (ou le rendre résilient).

Cela empêcherait la boucle de crash silencieuse down: 1s qui arrête toutes les tâches d’arrière-plan/IA.

Je suis disponible pour tester n’importe quelle branche/commit que vous me signalez.