Forum inaccessible avec une erreur Redis dans les logs de unicorn (

Installation
1

Bonjour.

J’héberge deux forums sur ma machine, tous deux sont à jour (3.4.0.beta3-dev pour l’un, et je ne peux pas vérifier celui qui n’est pas disponible).

L’un d’eux a été mis à jour plus tôt cette semaine et s’est soudainement arrêté de fonctionner il y a environ 2 jours.

Une fois connecté, un message « Oops » apparaît sur chaque page.

Je suis entré dans le conteneur et j’ai regardé les logs de unicorn et il semble y avoir un problème de connexion avec redis :

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'

Le problème est que je ne vois pas ce qui ne va pas, car je peux me connecter au serveur redis dans le conteneur via redis-cli et définir et obtenir des clés sans problème.

Je vois de nombreux problèmes similaires sur le forum mais ils sont soit anciens, soit n’ont pas eu de résolution. Quelqu’un peut-il aider ? Je peux fournir plus d’informations si nécessaire.

1 « J'aime »
2

Cela fonctionnait auparavant ?
Depuis quand avez-vous commencé ?
Vous avez deux versions d’un fichier app.yml standard, chacune avec son propre modèle Redis et postgres et des chemins différents vers les données ?
Une possibilité est les permissions. À un moment donné, l’identifiant de l’utilisateur et du groupe a changé, mais je n’ai jamais vu que cela posait problème dans les configurations à conteneur unique.

3

Merci d’avoir examiné mon problème.

Oui, cela fonctionnait jusqu’à il y a environ 3 jours. Cependant, ce matin, j’ai essayé d’exécuter une sauvegarde en ligne de commande depuis le conteneur et cela a échoué en raison d’une étrange erreur postgres, je soupçonne donc que la base de données est corrompue d’une manière ou d’une autre. Ce qui n’est pas du tout pertinent pour le message d’erreur que j’ai mentionné ci-dessus, mais je suis enclin à essayer de restaurer une sauvegarde fonctionnelle datant d’il y a 8 jours (le propriétaire du forum est d’accord) pour voir si cela résout tout.

Je suppose que je peux restaurer une sauvegarde d’une ancienne version de Discourse vers une version plus récente ? (puisqu’il y a eu une mise à jour entre la sauvegarde et maintenant.)

EDIT : pour clarifier, les deux forums sont des fichiers yaml différents, donc chacun a son propre conteneur pour fonctionner, et des répertoires de données différents évidemment.

4

A-t-il échoué lors de la sauvegarde ou de la restauration ?

Il serait utile que vous incluiez réellement l’étrange erreur, mais si c’était lors de la restauration, je soupçonne qu’il s’agit de celle décrite ici : Restore failing with missing chat_mention function

Si c’est le cas, mon conseil est d’attendre. Si attendre n’est pas une option, vous pourriez essayer de voir si le site que vous restaurez a le même commit que le site qui crée la sauvegarde.

5

C’est sur la sauvegarde.

pg_dump: error: Dumping the contents of table "posts" failed: PQgetResult() failed.
pg_dump: error: Error message from server: ERROR:  could not open file "base/16384/17044": No such file or directory

C’est pourquoi j’ai dit que j’essaierais d’abord de restaurer une sauvegarde pour voir si cela résolvait le problème. :slight_smile:

6

Cela semble effectivement être un problème de base de données.

Avez-vous déjà restauré une sauvegarde du système de fichiers ? Cela ressemble au genre de chose qui pourrait arriver si vous faisiez une sauvegarde du système de fichiers pendant que la base de données fonctionnait. C’est l’une des raisons pour lesquelles je ne recommande pas les sauvegardes du système de fichiers.

Si vous souhaitez restaurer une sauvegarde de Discourse, ce que je recommanderais généralement, vous devrez supprimer la base de données, puis créer et migrer une base de données vide avant d’effectuer la restauration.

7

Je fais des sauvegardes du système de fichiers mais j’exclus les bases de données postgres car je les sauvegarde à la place. Cependant, j’ai peut-être oublié d’exclure le dossier de discourse, je devrai vérifier cela plus tard.

Les informations contenues dans ce fil de discussion sont-elles toujours valides pour mon cas d’utilisation ?

8

La façon d’obtenir la sauvegarde là où vous en avez besoin semble inutilement compliquée.

9

D’accord, j’ai trouvé le coupable, merci de m’avoir orienté dans la bonne direction concernant le système de fichiers. Nous avons effectué une analyse antivirus et quelqu’un a téléchargé quelque chose sur le forum qui contenait une signature virale. Par conséquent, ClamAV a supprimé le fichier. Je vais mieux le régler pour qu’il ne mette plus en quarantaine les fichiers postgres.

Désolé d’avoir perdu votre temps :slight_smile:

1 « J'aime »
10

Génial ! Heureux que mon indice ait aidé ! Je n’y aurais jamais pensé, mais cela fait très longtemps que je n’ai pas utilisé de logiciel antivirus.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.