Sidekiq-Heartbeat-Test fehlgeschlagen, Neustart

Unterstützung Installation
1

Hallo! Ich habe einen seltsamen Fehler auf meiner Admin-Seite entdeckt: Sidekiq läuft nicht.
Ich habe die Logs geöffnet und hunderte Fehler wie diesen gefunden:

/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>'

Hier sind die Fehler aus der App:

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

Ich habe versucht, die Redis-Datenbank zu leeren, aber das hat nicht geholfen.
Ich habe separate Container für App, PostgreSQL und Redis.
Habt ihr eine Idee, wie ich das beheben kann?

2

Ist Sidekiq pausiert und häufen sich die Jobs in der Warteschlange an?

3

Es werden 2 Jobs in der Standardwarteschlange angezeigt, beide sind Jobs::VersionCheck.
Nach dem Leeren der Redis-Datenbank werden 0 abgeschlossene Jobs, 0 fehlgeschlagene Jobs und 2 Jobs in der Warteschlange angezeigt.

Auf der Scheduler-Seite werden einige Jobs als in der Warteschlange oder ausgeführt angezeigt, aber diese Jobs werden in den Statistiken der Sidekiq-Seite nicht gezählt. Alle Jobs auf der Scheduler-Seite haben eine leere Dauer oder -1 ms.

Die Zahlen summieren sich also nicht auf, es ändert sich buchstäblich nichts.
Wie kann ich prüfen, ob Sidekiq pausiert ist?

4

Das gleiche Problem hier mit dem neuesten Update, keine Änderungen außer einem Update durch einen Neuaufbau. Das Admin-Dashboard meldet, dass Sidekiq nicht läuft. Ich habe Postgres/Redis in einem Container und die App in einem anderen; ich habe sie alle erneut neu gestartet. Die Warteschlangen haben ein paar hundert Einträge, aber es wird nichts verarbeitet.

EDIT1: Das Löschen aller Warteschlangen hat nichts gefixt oder geholfen. Sie füllen sich wieder auf, und es wird immer noch nichts verarbeitet.

EDIT2: Und ich habe das Forum mit all den damit verbundenen Ausfallzeiten neu aufgebaut, und immer noch erscheint diese Meldung:

image
image1084×160 14.4 KB

Und die Warteschlangen werden in /sidekiq nicht verarbeitet. Das hat alles vor dem Update von beta7 auf 2.4.0.beta9 problemlos funktioniert.

EDIT3: Über 50 GB freier Speicherplatz. Ein manuelles Backup (knapp unter 300 MB) läuft erfolgreich durch, und es wird gemeldet, dass Sidekiq pausiert und dann wieder fortgesetzt wird, ohne dass im Log ein Fehler erscheint, aber Sidekiq scheint immer noch nicht zu laufen?

EDIT4: Das einzige bemerkenswerte Log in /logs ist die sich wiederholende Meldung Sidekiq heartbeat test failed, restarting.

EDIT5: Redis scheint in Ordnung zu sein und funktioniert; zumindest ist die Log-Datei damit beschäftigt zu melden, dass es nicht viel zu tun hat… Und zur Klarheit:

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

EDIT6: Ich habe die Warteschlangen vor einer Weile geleert, jetzt sind wieder 10 Aufgaben in der Warteschlange, die nicht verarbeitet werden.

EDIT7: Ich habe herausgefunden, dass bundle exec sidekiq der übliche Weg ist, Sidekiq in einem normalen Projekt zu starten. Also versuchen wir es mal, um zu sehen, was passiert:

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/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)>'
/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

Nun, das sieht interessant aus? Lassen Sie uns den Datencontainer neu aufbauen und beten, dass wir das Daten-Verzeihen nicht berühren, lol…

EDIT8: Nun, es scheint Redis 5.0.5 zu laufen (warum wird dafür nicht PostgreSQL-PubSub verwendet?), was definitiv 4.0.0 oder neuer ist… und der Neuaufbau ist abgeschlossen. Ich teste das Forum, die Daten scheinen noch da zu sein, und wir haben einen Anstieg!

image
image367×572 61.8 KB

Sieht aus, als wäre es behoben! Vielleicht ist dieser Beitrag für jemanden nützlich. Ich wünschte, das Forum hätte mir den Fehler von Sidekiq bezüglich einer veralteten Redis-Version angezeigt, aber ich vermute, diese Logs landen irgendwo im Nirgendwo, da ich sie nirgends gesehen habe. ^.^

5

Das ist eine sehr gute Detektivarbeit, ich hoffe, sie hilft anderen.

6

Wie hast du eine alte Redis-Version bekommen? Verwendest du eine nicht standardmäßige Installation?

7

Ich verwende ein Multicontainer-Setup und habe Redis nie neu aufgebaut.
Ich werde versuchen, Redis neu aufzubauen.

UPDATE:
@OvermindDL1, danke für die Lösungen. Ich habe den Redis-Container neu aufgebaut, und jetzt funktioniert alles.

Sidekiq ist eine Bibliothek für Hintergrundaufgaben und hängt von Redis ab. Sie ist hochgradig optimiert und ausgereift, unterstützt aber nur das Redis-Backend.
Ich denke auch, dass message_bus (Echtzeitfunktionen von Discourse) im Hintergrund Redis verwendet.

8

Standard-Docker-Split-Container-Installation gemäß den Anweisungen (damit ich eine neue Discourse-Version erstellen und dann schnell zwischen ihnen wechseln kann, ohne Ausfallzeiten), aber ich greife nicht auf den Datencontainer zu, in dem Redis anscheinend läuft (ich ging davon aus, dass dies im Hauptcontainer wäre; ich war überrascht, als ich es im Hauptcontainer nicht fand).

Ja, genau dasselbe wie @arrowcircle hier. :slight_smile:

9

In einer 2-Container-Setup müssen Sie den Datencontainer dennoch neu aufbauen. Ich empfehle, dies mindestens einmal jährlich zu planen.

10

Gibt es eine Möglichkeit, dies ohne Ausfallzeit zu tun? Das war ja der Punkt, sie anfangs zu trennen.

11

Für eine Ausfallzeit von null müssten Sie ein Redis-Replica und eine Datenbank-Replica betreiben. Beim Failover würden Sie dennoch eine kurze Phase nur für Lesezugriffe durchlaufen.

Ja, all das ist möglich, aber Sie müssten ein Infrastrukturteam einstellen.

12

Alles hier ist Open Source, ohne Geld. ^.^;