Forum nicht verfügbar mit Redis-Fehler in den Unicorn-Protokollen (

[AxelTerizaki]

Hallo.

Ich hoste zwei Foren auf meinem Computer, beide sind auf dem neuesten Stand (eine davon 3.4.0.beta3-dev, und die, die nicht verfügbar ist, kann ich nicht überprüfen).

Eines davon wurde diese Woche aktualisiert und funktionierte plötzlich vor etwa 2 Tagen nicht mehr.

Nach der Anmeldung erscheint auf jeder Seite eine “Ups”-Meldung.

Ich bin in den Container gegangen und habe mir die Unicorn-Logs angesehen. Es scheint ein Problem beim Verbinden mit Redis zu geben:

Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

Das Problem ist, dass ich nicht sehe, was falsch ist, da ich mich über redis-cli problemlos mit dem Redis-Server im Container verbinden und Schlüssel setzen und abrufen kann.

Ich sehe viele ähnliche Probleme im Forum, aber sie sind entweder alt oder wurden nicht gelöst. Kann mir jemand helfen? Ich kann bei Bedarf weitere Informationen bereitstellen.

[pfaffman (Jay Pfaffman)]

Das hat früher funktioniert?
Wann haben Sie angefangen?
Sie haben zwei Versionen einer Standard-app.yml-Datei, jede mit ihrer eigenen Redis- und Postgres-Vorlage und unterschiedlichen Pfaden zu den Daten?
Eine Möglichkeit sind Berechtigungen. Irgendwann hat sich die ID des Benutzers und der Gruppe geändert, aber ich habe das bei Einzelcontainer-Setups noch nie als Problem gesehen.

[AxelTerizaki]

Vielen Dank, dass Sie sich mein Problem angesehen haben.

Ja, das hat bis vor etwa 3 Tagen funktioniert. Heute Morgen habe ich jedoch versucht, ein Backup über die CLI aus dem Container heraus auszuführen, und es schlug aufgrund eines seltsamen Postgres-Fehlers fehl, daher vermute ich, dass die Datenbank irgendwie beschädigt ist. Was für die oben genannte Fehlermeldung überhaupt nicht relevant ist, aber ich neige dazu, zu versuchen, ein funktionierendes Backup von vor 8 Tagen wiederherzustellen (der Forenbesitzer ist damit einverstanden), um zu sehen, ob alles gelöst wird.

Ich nehme an, ich kann ein Backup von einer älteren Version von Discourse auf eine neuere wiederherstellen? (da es zwischen dem Backup und jetzt ein Update gab.)

EDIT: Zur Klarstellung: Die beiden Foren sind unterschiedliche YAML-Dateien, daher hat jedes seinen eigenen Container und offensichtlich unterschiedliche Datenverzeichnisse.

[pfaffman (Jay Pfaffman)]

@AxelTerizaki

es ist aufgrund eines seltsamen Postgres-Fehlers fehlgeschlagen

Ist es beim Backup oder beim Wiederherstellen fehlgeschlagen?

Es wäre hilfreich, wenn Sie den seltsamen Fehler tatsächlich angeben würden, aber wenn es beim Wiederherstellen war, vermute ich, dass es sich um den hier beschriebenen handelt: Restore failing with missing chat_mention function

Wenn das zutrifft, ist mein Rat, zu warten. Wenn Warten keine Option ist, könnten Sie versuchen, sicherzustellen, dass die wiederhergestellte Website den gleichen Commit wie die Website hat, die das Backup erstellt.

[AxelTerizaki]

Es ist auf dem Backup.

pg_dump: Fehler: Das Sichern des Inhalts der Tabelle „posts“ ist fehlgeschlagen: PQgetResult() ist fehlgeschlagen.
pg_dump: Fehler: Fehlermeldung vom Server: ERROR:  could not open file "base/16384/17044": No such file or directory

Deshalb sagte ich, ich würde zuerst versuchen, ein Backup wiederherzustellen, um zu sehen, ob das Problem dadurch behoben wird.

[pfaffman (Jay Pfaffman)]

Das scheint tatsächlich ein Datenbankproblem zu sein.

Haben Sie schon einmal ein Dateisystem-Backup wiederhergestellt? Das klingt nach der Art von Problem, die auftreten würde, wenn Sie ein Dateisystem-Backup erstellen, während die Datenbank läuft. Das ist einer der Gründe, warum ich keine Dateisystem-Backups empfehle.

Wenn Sie ein Discourse-Backup wiederherstellen möchten, was ich normalerweise empfehlen würde, müssten Sie die Datenbank löschen und eine leere Datenbank erstellen und migrieren, bevor Sie die Wiederherstellung durchführen.

[AxelTerizaki]

Ich mache Dateisystem-Backups, schließe aber PostgreSQL-Datenbanken aus, da ich sie stattdessen dumpfe. Möglicherweise habe ich jedoch vergessen, den Ordner von Discourse auszuschließen. Das muss ich später überprüfen.

Sind die Informationen in diesem Thread für meinen Anwendungsfall noch gültig?

[pfaffman (Jay Pfaffman)]

Die Sache, wie man das Backup dorthin bekommt, wo man es braucht, scheint unnötig kompliziert zu sein.

[AxelTerizaki]

Okay, ich habe den Schuldigen gefunden, danke, dass Sie mich in die richtige Richtung bezüglich des Dateisystems gewiesen haben. Wir haben einen Virenscan durchgeführt und jemand hat etwas im Forum hochgeladen, das eine Virensignatur hatte. Infolgedessen hat ClamAV die Datei entfernt. Ich werde es besser abstimmen, damit es keine PostgreSQL-Dateien mehr unter Quarantäne stellt.

Entschuldigen Sie die Zeitverschwendung

[pfaffman (Jay Pfaffman)]

Großartig! Froh, dass mein Hinweis geholfen hat! Ich wäre nie darauf gekommen, aber ich benutze schon sehr lange keine Virenschutzsoftware mehr.