Échec du test de battement de cœur Sidekiq, redémarrage en cours

Soutien Installation
1

Bonjour ! J’ai trouvé une erreur étrange sur ma page d’administration : Sidekiq ne fonctionne pas.
J’ai ouvert les journaux et découvert des centaines d’erreurs comme :

/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:112:in `report_to_store'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:103:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:54:in `add'
/usr/local/lib/ruby/2.6.0/logger.rb:534:in `warn'
config/unicorn.conf.rb:147:in `check_sidekiq_heartbeat'
config/unicorn.conf.rb:164:in `master_sleep'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:296:in `join'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

Voici les erreurs provenant de l’application :

run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/letsencrypt
[Wed 01 Jan 2020 10:40:41 AM UTC] Domains not changed.
[Wed 01 Jan 2020 10:40:41 AM UTC] Skip, Next renewal time is: Tue Feb 25 00:52:11 UTC 2020
[Wed 01 Jan 2020 10:40:41 AM UTC] Add '--force' to force to renew.
[Wed 01 Jan 2020 10:40:41 AM UTC] Installing key to:/shared/ssl/discourse.example.com.key
[Wed 01 Jan 2020 10:40:41 AM UTC] Installing full chain to:/shared/ssl/discourse.example.com.cer
[Wed 01 Jan 2020 10:40:41 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Wed 01 Jan 2020 10:40:41 AM UTC] Reload error for :
[Wed 01 Jan 2020 10:40:42 AM UTC] Domains not changed.
[Wed 01 Jan 2020 10:40:42 AM UTC] Skip, Next renewal time is: Wed Jan  8 00:39:10 UTC 2020
[Wed 01 Jan 2020 10:40:42 AM UTC] Add '--force' to force to renew.
[Wed 01 Jan 2020 10:40:42 AM UTC] Installing key to:/shared/ssl/discourse.example.com_ecc.key
[Wed 01 Jan 2020 10:40:42 AM UTC] Installing full chain to:/shared/ssl/discourse.example.com_ecc.cer
[Wed 01 Jan 2020 10:40:42 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Wed 01 Jan 2020 10:40:42 AM UTC] Reload error for :
Started runsvdir, PID is 628
chgrp: invalid group: ‘syslog’
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.1901.0 try https://www.rsyslog.com/e/2145 ]
supervisor pid: 633 unicorn pid: 647

J’ai essayé de vider la base de données Redis, mais cela n’a pas aidé.
J’ai des conteneurs séparés pour l’application, PostgreSQL et Redis.
Avez-vous des idées pour résoudre ce problème ?

2

Sidekiq est-il en pause ? La file d’attente des tâches s’accumule-t-elle ?

3

Il affiche 2 jobs dans la file d’attente par défaut, tous deux sont Jobs::VersionCheck.
Après avoir vidé la base de données Redis, il affiche 0 jobs terminés, 0 échoués, 2 en file d’attente.

La page du planificateur indique que certains jobs sont en file d’attente ou en cours d’exécution, mais ces jobs ne sont pas comptabilisés dans les statistiques de la page Sidekiq. Tous les jobs sur la page du planificateur ont une durée vide ou de -1 ms.

Les chiffres ne s’accumulent donc pas, rien ne change littéralement.
Comment vérifier si Sidekiq est en pause ?

4

Même problème ici avec la dernière mise à jour, aucun changement autre que la simple mise à jour via une reconstruction. Le tableau de bord d’administration indique que Sidekiq n’est pas en cours d’exécution. J’ai PostgreSQL et Redis dans un conteneur et l’application dans un autre ; je les ai tous redémarrés également. Les files d’attente en comptent plusieurs centaines, mais rien n’est traité.

EDIT1 : Vider toutes les files d’attente n’a rien résolu ni aidé ; elles se remplissent à nouveau et rien n’est toujours traité.

EDIT2 : J’ai reconstruit le forum avec tout l’arrêt que cela implique, et j’ai toujours ce message :

image
image1084×160 14.4 KB

Et les files d’attente ne sont toujours pas traitées dans /sidekiq. Tout cela fonctionnait sans problème avant la mise à jour vers 2.4.0.beta9 depuis beta7.

EDIT3 : Plus de 50 Go d’espace libre. L’exécution manuelle d’une sauvegarde (un peu moins de 300 Mo) réussit, et il est indiqué que Sidekiq est mis en pause puis repris, sans erreur signalée dans le journal, mais Sidekiq semble toujours ne pas être en cours d’exécution ?

EDIT4 : Le seul journal notable dans /logs est le message « Sidekiq heartbeat test failed, restarting » qui se répète sans cesse.

EDIT5 : Redis semble être actif et fonctionner correctement, du moins son fichier journal est occupé à dire qu’il n’a pas grand-chose à faire… Et pour plus de clarté :

[3] pry(main)> Sidekiq.paused?
=> false

EDIT6 : J’ai vidé les files d’attente il y a un moment, elles sont remontées à 10 tâches en attente mais non traitées.

EDIT7 : J’ai découvert que bundle exec sidekiq est la méthode habituelle pour démarrer Sidekiq dans un projet normal, alors essayons de l’exécuter pour voir ce qu’il se passe :

root@vps198273-forum:/var/www/discourse# bundle exec sidekiq
2020-01-06T05:10:18.814Z pid=31242 tid=gn383wxbu INFO: Booting Sidekiq 6.0.4 with redis options {:host=>"forum-data", :port=>6379, :namespace=>"sidekiq", :id=>"Sidekiq-server-PID-31242", :url=>nil}
You are connecting to Redis v3.0.6, Sidekiq requires Redis v4.0.0 or greater
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/lib/sidekiq/cli.rb:62:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:12:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/sidekiq:23:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'

You are connecting to Redis v3.0.6, Sidekiq requires Redis v4.0.0 or greater

Eh bien, cela semble intéressant ? Essayons de reconstruire le conteneur de données en priant pour ne pas toucher aux données, lol…

EDIT8 : Eh bien, il semble que Redis 5.0.5 soit en cours d’exécution (pourquoi n’utilise-t-on pas la publication/abonnement de PostgreSQL pour cela ?), ce qui est bien sûr 4.0.0 ou plus récent… et la reconstruction est terminée. Je teste le forum, les données semblent toujours être là, et nous avons un pic !

image
image367×572 61.8 KB

Ça semble réparé ! Peut-être que ce post sera utile à quelqu’un. J’aurais aimé que le forum m’affiche l’erreur que Sidekiq donnait concernant une version obsolète de Redis, mais je suppose que ces journaux sont simplement envoyés dans l’abîme quelque part, car je ne les ai vus nulle part. ^.^

5

C’est une excellente déduction, j’espère que cela aidera d’autres personnes.

6

Comment as-tu obtenu un Redis ancien ? Utilises-tu une installation non standard ?

7

J’utilise une configuration multi-conteneurs et je n’ai jamais reconstruit Redis.
Je vais essayer de reconstruire Redis.

MISE À JOUR.
@OvermindDL1, merci pour les solutions. J’ai reconstruit le conteneur Redis et tout fonctionne maintenant.

Sidekiq est une bibliothèque de tâches en arrière-plan qui dépend de Redis. Elle est super optimisée et mature, mais ne prend en charge que le backend Redis.
Je pense aussi que message_bus (les fonctionnalités en temps réel de Discourse) utilise Redis en coulisses.

8

Installation Docker standard avec conteneurs séparés, conformément aux instructions (afin de pouvoir construire une nouvelle version de Discourse et effectuer un remplacement rapide sans interruption de service), mais je ne touche pas au conteneur de données, où Redis semble s’exécuter (je pensais qu’il serait dans le conteneur principal ; j’ai été surpris de ne pas le trouver en cours d’exécution dans celui-ci).

Oui, exactement la même chose que @arrowcircle ici. :slight_smile:

9

Dans une configuration à 2 conteneurs, vous devez toujours reconstruire le conteneur de données. Je vous recommande de planifier cette opération au moins une fois par an.

10

Y a-t-il un moyen de faire cela sans interruption de service ? C’était là l’objectif de les séparer initialement.

11

Pour un temps d’arrêt nul, vous devrez exécuter un Redis en réplique et une base de données en réplique. Vous aurez tout de même une phase de lecture seule brève lors du basculement.

Oui, tout cela est possible, mais vous devrez embaucher une équipe d’infrastructure.

12

Tout le contenu open source ici, sans argent. ^.^;