Erreur de connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

Soutien Installation
1

Après avoir installé Discourse avec « Docker version 20.10.5, build 55c4c8 » sur CentOS 8, le site est opérationnel, mais il échoue systématiquement avec un délai d’attente lors des appels DELETE vers /draft.json.

Apache est en cours d’exécution et j’ai testé à la fois avec un proxy inverse Apache et avec HAProxy, mais le comportement est identique.

Je ne sais pas si cela est lié, mais je constate de nombreuses erreurs de ce type dans unicorn.stdout.log :

==> ./shared/standalone/log/rails/unicorn.stdout.log <==

2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Erreur lors de la récupération du travail : Échec de la connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

Démarrage de 1 sidekiq supervisé

Chargement de Sidekiq dans le processus d'identifiant 119

2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Erreur lors de la récupération du travail : Échec de la connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Erreur lors de la récupération du travail : Échec de la connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Erreur lors de la récupération du travail : Échec de la connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Erreur lors de la récupération du travail : Échec de la connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Erreur lors de la récupération du travail : Échec de la connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

Démarrage de 1 sidekiq supervisé

Chargement de Sidekiq dans le processus d'identifiant 121
2

Redis enregistre-t-il des erreurs dans /var/discourse/shared/standalone/log/var-log/redis ?

2 « J'aime »
3

Voici le contenu de « current » :

53:M 18 Mar 2021 17:07:05.076 * 10 modifications en 300 secondes. Sauvegarde en cours...
53:M 18 Mar 2021 17:07:05.076 * Sauvegarde en arrière-plan démarrée par le processus 25018
25018:C 18 Mar 2021 17:07:05.126 * Base de données sauvegardée sur le disque
25018:C 18 Mar 2021 17:07:05.127 * RDB : 2 Mo de mémoire utilisés par copy-on-write
53:M 18 Mar 2021 17:07:05.177 * Sauvegarde en arrière-plan terminée avec succès
53:M 18 Mar 2021 17:12:06.097 * 10 modifications en 300 secondes. Sauvegarde en cours...
53:M 18 Mar 2021 17:12:06.098 * Sauvegarde en arrière-plan démarrée par le processus 25337
25337:C 18 Mar 2021 17:12:06.145 * Base de données sauvegardée sur le disque
25337:C 18 Mar 2021 17:12:06.145 * RDB : 2 Mo de mémoire utilisés par copy-on-write
53:M 18 Mar 2021 17:12:06.198 * Sauvegarde en arrière-plan terminée avec succès
1 « J'aime »
4

Ces journaux me semblent corrects. Rencontrez-vous toujours des problèmes lors de la navigation sur votre instance Discourse ?

1 « J'aime »
5

Je ne peux toujours pas supprimer les publications, les invitations et les modifications de publications invalidées.

Il semble y avoir un problème sur tous les appels utilisant la méthode HTTP DELETE. Puis-je dire que Discourse devrait utiliser POST au lieu de DELETE ? Cela ressemble à How can Discourse make POST instead of DELETE for "smart" CDN?, mais je n’utilise aucun CDN, juste un serveur virtuel standard avec une installation CentOS et Docker selon les instructions du site de Discourse.

image
image768×390 21.9 KB

image
image2654×1132 336 KB

image
image2262×644 157 KB

1 « J'aime »
6

Extrait du journal Haproxy avec des erreurs 408 sur HTTP DELETE. Que peut signifier « dropping » les requêtes DELETE @codinghorror ? Si ces requêtes DELETE atteignent Haproxy, elles devraient également atteindre le logiciel à l’intérieur de Docker. Quelque chose là-dedans peut-il être « responsable » du problème ?

Mar 20 01:47:46 id22302.example.com haproxy[43043]: 176.243.177.232:61760 [20/Mar/2021:01:47:16.622] http-in discourse_socket/server3 0/0/0/30004/30034 408 71 - - CD-- 3/3/2/2/0 0/0 "DELETE /draft.json HTTP/1.1"

Mar 20 01:47:46 id22302.example.com haproxy[43043]: 176.243.177.232:61760 [20/Mar/2021:01:47:16.622] http-in discourse_socket/server3 0/0/0/30004/30034 408 71 - - CD-- 3/3/2/2/0 0/0 "DELETE /draft.json HTTP/1.1"

Mar 20 01:48:09 id22302.example.com haproxy[43043]: 176.243.177.232:61505 [20/Mar/2021:01:47:43.921] http-in discourse_socket/server3 0/0/0/25081/25081 200 396 - - ---- 2/2/1/1/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll HTTP/1.1"

Mar 20 01:48:09 id22302.example.com haproxy[43043]: 176.243.177.232:61505 [20/Mar/2021:01:47:43.921] http-in discourse_socket/server3 0/0/0/25081/25081 200 396 - - ---- 2/2/1/1/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll HTTP/1.1"

Mar 20 01:48:12 id22302.example.com haproxy[43043]: 176.243.177.232:61887 [20/Mar/2021:01:47:42.886] http-in discourse_socket/server3 0/0/0/30007/30037 408 71 - - CD-- 2/2/1/1/0 0/0 "DELETE /draft.json HTTP/1.1"

Mar 20 01:48:12 id22302.example.com haproxy[43043]: 176.243.177.232:61887 [20/Mar/2021:01:47:42.886] http-in discourse_socket/server3 0/0/0/30007/30037 408 71 - - CD-- 2/2/1/1/0 0/0 "DELETE /draft.json HTTP/1.1"

Mar 20 01:48:25 id22302.example.com haproxy[43043]: 176.243.177.232:62083 [20/Mar/2021:01:48:25.863] http-in discourse_socket/server3 0/0/0/122/122 200 404 - - ---- 2/2/1/1/0 0/0 "POST /topics/timings HTTP/1.1"

Mar 20 01:48:25 id22302.example.com haproxy[43043]: 176.243.177.232:62083 [20/Mar/2021:01:48:25.863] http-in discourse_socket/server3 0/0/0/122/122 200 404 - - ---- 2/2/1/1/0 0/0 "POST /topics/timings HTTP/1.1"

Mar 20 01:48:34 id22302.example.com haproxy[43043]: 176.243.177.232:61505 [20/Mar/2021:01:48:09.193] http-in discourse_socket/server3 0/0/0/25044/25044 200 396 - - ---- 2/2/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll HTTP/1.1"

Mar 20 01:48:34 id22302.example.com haproxy[43043]: 176.243.177.232:61505 [20/Mar/2021:01:48:09.193] http-in discourse_socket/server3 0/0/0/25044/25044 200 396 - - ---- 2/2/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll HTTP/1.1"

Mar 20 01:48:59 id22302.example.com haproxy[43043]: 176.243.177.232:61505 [20/Mar/2021:01:48:34.487] http-in discourse_socket/server3 0/0/0/25087/25087 200 396 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll HTTP/1.1"

Mar 20 01:48:59 id22302.example.com haproxy[43043]: 176.243.177.232:61505 [20/Mar/2021:01:48:34.487] http-in discourse_socket/server3 0/0/0/25087/25087 200 396 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll HTTP/1.1"

Mar 20 01:49:35 id22302.example.com haproxy[43043]: 176.243.177.232:62413 [20/Mar/2021:01:49:35.637] http-in discourse_socket/server3 0/0/0/87/87 200 417 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll?dlp=t HTTP/1.1"

Mar 20 01:49:35 id22302.example.com haproxy[43043]: 176.243.177.232:62413 [20/Mar/2021:01:49:35.637] http-in discourse_socket/server3 0/0/0/87/87 200 417 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll?dlp=t HTTP/1.1"

Mar 20 01:50:36 id22302.example.com haproxy[43043]: 176.243.177.232:62714 [20/Mar/2021:01:50:36.568] http-in discourse_socket/server3 0/0/0/81/81 200 417 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll?dlp=t HTTP/1.1"

Mar 20 01:50:36 id22302.example.com haproxy[43043]: 176.243.177.232:62714 [20/Mar/2021:01:50:36.568] http-in discourse_socket/server3 0/0/0/81/81 200 417 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll?dlp=t HTTP/1.1"

Mar 20 01:51:37 id22302.example.com haproxy[43043]: 176.243.177.232:62993 [20/Mar/2021:01:51:37.541] http-in discourse_socket/server3 0/0/0/78/78 200 417 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll?dlp=t HTTP/1.1"

Mar 20 01:51:37 id22302.example.com haproxy[43043]: 176.243.177.232:62993 [20/Mar/2021:01:51:37.541] http-in discourse_socket/server3 0/0/0/78/78 200 417 - - ---- 1/1/0/0/0 0/0 "POST /message-bus/742b0b89384944a7b6376e2d6978889d/poll?dlp=t HTTP/1.1"
7

Voici production.log : je ne vois jamais de requête de suppression apparaître, mais je vois tout le reste enregistré (ouverture de sujet, modification, enregistrement, etc.) :

Terminé 200 OK en 81 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 14861)

Démarrage de GET "/composer_messages?composer_action=edit&topic_id=10&post_id=13" pour 176.243.226.205 le 2021-03-20 15:51:09 +0100

Traitement par ComposerMessagesController#index en JSON

Paramètres : {"composer_action" => "edit", "topic_id" => "10", "post_id" => "13"}

Terminé 200 OK en 1191 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 16940)

Démarrage de POST "/presence/publish" pour 176.243.226.205 le 2021-03-20 15:51:14 +0100

Traitement par Presence::PresencesController#handle_message en */*

Paramètres : {"state" => "editing", "topic_id" => "10", "post_id" => "13"}

Terminé 200 OK en 9 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 3192)

Démarrage de PUT "/t/e-previsto-un-ritorno-di-freddo-nutro/10" pour 176.243.226.205 le 2021-03-20 15:51:17 +0100

Traitement par TopicsController#update en */*

Paramètres : {"title" => "E' previsto un ritorno di freddo, nutro?", "category_id" => 1, "slug" => "e-previsto-un-ritorno-di-freddo-nutro", "topic_id" => "10", "topic" => {"title" => "E' previsto un ritorno di freddo, nutro?", "category_id" => 1}}

Terminé 200 OK en 19 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 5149)

Démarrage de POST "/presence/publish" pour 176.243.226.205 le 2021-03-20 15:51:17 +0100

Traitement par Presence::PresencesController#handle_message en */*

Paramètres : {"state" => "closed", "topic_id" => "10"}

Terminé 200 OK en 10 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 3159)

Démarrage de PUT "/posts/13" pour 176.243.226.205 le 2021-03-20 15:51:17 +0100

Traitement par PostsController#update en */*

Paramètres : {"post" => {"edit_reason" => "", "cooked" => "<p>post di test per vedere. ssss</p>", "raw" => "post di test per vedere. ssss", "topic_id" => "10", "raw_old" => ""}, "id" => "13"}

Terminé 200 OK en 3296 ms (Vues : 0,1 ms | ActiveRecord : 0,0 ms | Allocations : 86638)

Démarrage de GET "/t/10.json" pour 176.243.226.205 le 2021-03-20 15:51:20 +0100

Traitement par TopicsController#show en JSON

Paramètres : {"id" => "10"}

Terminé 200 OK en 143 ms (Vues : 0,1 ms | ActiveRecord : 0,0 ms | Allocations : 52707)

Démarrage de GET "/draft.json?draft_key=topic_10" pour 176.243.226.205 le 2021-03-20 15:51:27 +0100

Traitement par DraftController#show en JSON

Paramètres : {"draft_key" => "topic_10"}

Terminé 200 OK en 38 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 4317)

Démarrage de GET "/posts/13" pour 176.243.226.205 le 2021-03-20 15:51:27 +0100

Traitement par PostsController#show en JSON

Paramètres : {"id" => "13"}

Terminé 200 OK en 16 ms (Vues : 0,1 ms | ActiveRecord : 0,0 ms | Allocations : 5026)

Démarrage de POST "/presence/publish" pour 176.243.226.205 le 2021-03-20 15:51:29 +0100

Traitement par Presence::PresencesController#handle_message en */*

Paramètres : {"state" => "editing", "topic_id" => "10", "post_id" => "13"}

Terminé 200 OK en 20 ms (Vues : 0,3 ms | ActiveRecord : 0,0 ms | Allocations : 3304)

Démarrage de GET "/posts/13" pour 176.243.226.205 le 2021-03-20 15:51:38 +0100

Traitement par PostsController#show en JSON

Paramètres : {"id" => "13"}

Terminé 200 OK en 121 ms (Vues : 0,2 ms | ActiveRecord : 0,0 ms | Allocations : 56890)
8

De plus, le journal PUMA n’affiche pas les requêtes DELETE

2021-03-20 16:01:38 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:01:38 +0100] "GET /t/e-previsto-un-ritorno-di-freddo-nutro/10 HTTP/1.1" 200 - 1.0685

2021-03-20 16:01:39 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:01:39 +0100] "GET /uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png HTTP/1.1" 200 11945 0.0119

2021-03-20 16:01:39 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021 16:01:39] "POST /message-bus/557c51e14e57450c8c76ab216af0a279/poll HTTP/1.1" HIJACKED -1 0.0956

2021-03-20 16:01:42 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:01:42 +0100] "POST /message-bus/557c51e14e57450c8c76ab216af0a279/poll HTTP/1.1" 200 - 0.0128

2021-03-20 16:01:43 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021 16:01:43] "POST /message-bus/557c51e14e57450c8c76ab216af0a279/poll HTTP/1.1" HIJACKED -1 0.0886

2021-03-20 16:01:54 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:01:54 +0100] "GET /t/e-previsto-un-ritorno-di-freddo-nutro/10 HTTP/1.1" 200 - 0.1436

2021-03-20 16:01:55 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:01:55 +0100] "GET /uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png HTTP/1.1" 200 11945 0.0383

2021-03-20 16:01:56 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021 16:01:56] "POST /message-bus/1bddd2f9aaf54ec5a589bc74c9c8a409/poll HTTP/1.1" HIJACKED -1 0.0453

2021-03-20 16:01:59 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:01:59 +0100] "POST /message-bus/1bddd2f9aaf54ec5a589bc74c9c8a409/poll HTTP/1.1" 200 - 0.0129

2021-03-20 16:01:59 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021 16:01:59] "POST /message-bus/1bddd2f9aaf54ec5a589bc74c9c8a409/poll HTTP/1.1" HIJACKED -1 0.0096

2021-03-20 16:02:07 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:02:07 +0100] "GET /draft.json?draft_key=topic_10 HTTP/1.1" 200 - 0.0131

2021-03-20 16:02:08 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:02:08 +0100] "GET /posts/13 HTTP/1.1" 200 - 0.3559

2021-03-20 16:02:08 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:02:08 +0100] "GET /composer_messages?composer_action=edit&topic_id=10&post_id=13 HTTP/1.1" 200 - 0.2087

2021-03-20 16:02:12 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021:16:02:12 +0100] "POST /presence/publish HTTP/1.1" 200 - 0.0155

2021-03-20 16:02:24 +0100 : |Puma| 176.243.226.205 - - [20/Mar/2021 16:02:24] "POST /message-bus/1bddd2f9aaf54ec5a589bc74c9c8a409/
9

Cela signifie que votre proxy inverse est mal configuré et qu’il rejette les requêtes autres que GET/POST. C’est un problème assez courant, et l’une des raisons pour lesquelles nous fournissons un proxy inverse préconfiguré à l’intérieur du conteneur, afin que les utilisateurs n’aient pas à s’en occuper.

Si vous supprimez HAProxy et laissez le conteneur lui-même écouter sur les ports 80/443, le problème persiste-t-il ?

2 « J'aime »
10

@Falco Je viens d’essayer, le problème persiste. Est-ce que cela pourrait être Puma lui-même, en tant que serveur web, qui rejette les requêtes DELETE ?

11

Nous n’utilisons pas Puma en production si vous l’installez conformément à l’installation standard officielle de Discourse.

Nous utilisons les verbes DELETE/PUT dans toute l’application pour chaque installation, et nous ne constatons aucun problème. Je suppose donc que cela est spécifique à votre installation.

C’est un peu tiré par les cheveux, mais avez-vous un WAF de quelque sorte qui protège ce domaine @Andrea_Giovacchini ?

2 « J'aime »
12

J’ai tenté une installation alternative après avoir essayé la version officielle qui présentait le même problème.

J’ai maintenant réessayé la configuration officielle (discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub), mais cela échoue lors de l’exécution de “./launcher rebuild app” avec le message suivant (il y a deux jours, cela ne plantait pas, mais était également affecté par le problème de DELETE) :

Assurez-vous que `gem install libv8 -v '8.4.255.0' --source 'https://rubygems.org/'` réussit avant de lancer bundler.

Dans le fichier Gemfile :
  mini_racer a été résolu vers 0.3.1, qui dépend de
    libv8

/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:220:in `handle_error'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:102:in `call'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:71:in `call'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:270:in `install_in_parallel'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:210:in `install'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:90:in `block in run'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:12:in `block in lock'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `open'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `lock'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:72:in `run'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:24:in `install'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli/install.rb:64:in `run'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:259:in `block in install'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/settings.rb:115:in `temporary'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:258:in `install'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:30:in `dispatch'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:24:in `start'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:49:in `block in <top (required)>'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
  /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:37:in `<top (required)>'
  /usr/local/bin/bundle:23:in `load'
  /usr/local/bin/bundle:23:in `<main>'

I, [2021-03-20T23:42:40.998961 #1]  INFO -- : Terminaison des processus asynchrones
I, [2021-03-20T23:42:40.998991 #1]  INFO -- : Envoi de INT à HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 66
I, [2021-03-20T23:42:40.999030 #1]  INFO -- : Envoi de TERM à exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 183
2021-03-20 23:42:40.999 UTC [66] LOG:  demande d'arrêt rapide reçue
183:signal-handler (1616283760) SIGTERM reçu, planification de l'arrêt...
2021-03-20 23:42:41.013 UTC [66] LOG:  annulation de toutes les transactions actives
2021-03-20 23:42:41.014 UTC [66] LOG:  l'ouvrier d'arrière-plan "logical replication launcher" (PID 75) s'est terminé avec le code de sortie 1
2021-03-20 23:42:41.016 UTC [70] LOG:  arrêt en cours
183:M 20 Mar 2021 23:42:41.058 # Arrêt demandé par l'utilisateur...
183:M 20 Mar 2021 23:42:41.058 * Sauvegarde de l'instantané RDB final avant la sortie.
183:M 20 Mar 2021 23:42:41.061 * Base de données sauvegardée sur le disque
183:M 20 Mar 2021 23:42:41.061 # Redis est maintenant prêt à quitter, au revoir...
2021-03-20 23:42:41.263 UTC [66] LOG:  le système de base de données est arrêté


ÉCHEC
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' a échoué avec le code de retour #<Process::Status: pid 348 exit 5>
Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}
9b0ca932a7dd52ccdd11e268910e3edcd8369c0c08f65e7f8686d542b9be473b
** ÉCHEC DU BOOTSTRAP ** veuillez remonter et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.
➜  discourse git:(master) ✗
13

@Falco J’ai réessayé la configuration officielle avec « tests-passed » au lieu de stable, et cela ne génère plus l’erreur du gem mini_racer, mais le problème de DELETE persiste, comme vous pouvez le voir dans la vidéo avec tail sur le journal nginx et le navigateur avec la console ouverte.

Les POSTS apparaissent immédiatement dans le journal nginx, tandis que les DELETE n’apparaissent qu’après l’erreur, ce qui est étrange.

Voici l’enregistrement de l’écran :
https://drive.google.com/file/d/1SEOdZjjVkQTpqT3ZQJ7SaR-Ib2mO6m4M/view?usp=sharing

Ce test a été effectué comme suggéré, en exécutant directement Discourse sur le port 80, sans autres logiciels comme HAPROXY intercalés.

2 « J'aime »
14

Super, je vais jeter un coup d’œil et essayer de reproduire le problème demain. Merci pour le signalement.

3 « J'aime »
15

Oui, la version « stable » est malheureusement actuellement cassée en raison d’une régression dans bundler.

Nous travaillerons sur une correction au cours des prochaines 24 heures.

2 « J'aime »
19

@Falco as-tu pu reproduire le problème ?

1 « J'aime »
22

Salut @Andrea_Giovacchini,

D’abord, il y a deux problèmes distincts :

  1. Les requêtes DELETE bloquées

  2. La reconstruction défaillante pour les utilisateurs sur la branche « stable ».

Le point 2 a été corrigé aujourd’hui via https://meta.discourse.org/t/cant-rebuild-current-stable/183859/6?u=falco

Pour le point 1, voici mes constatations :

J’ai une installation Discourse toute neuve en cours d’exécution, et lors de l’envoi d’une commande DELETE de test, j’obtiens :

curl -X DELETE https://falcoland.falco.dev/draft.json
["BAD CSRF"]%

Ce qui est attendu, car cette commande doit également être accompagnée d’un cookie valide pour la session utilisateur.

En revanche, sur votre site :

curl -X DELETE http://apicolturaitalianawebinar.it/draft.json -v
*   Trying 213.229.86.117:80...
* Connected to apicolturaitalianawebinar.it (213.229.86.117) port 80 (#0)
> DELETE /draft.json HTTP/1.1
> Host: apicolturaitalianawebinar.it
> User-Agent: curl/7.75.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Date: Mon, 22 Mar 2021 18:51:55 GMT
< Server: Apache/2.4.37 (centos) OpenSSL/1.1.1g Phusion_Passenger/6.0.4 mod_perl/2.0.11 Perl/v5.26.3
< X-Runtime: 0.001594
< X-Request-Id: ebe50251-0f06-4b71-acd0-887fb2666abb
< X-Powered-By: Phusion Passenger 6.0.4
< Content-Length: 1351
< Status: 404 Not Found
< Content-Type: text/html; charset=UTF-8
<

Je reçois une erreur 404 provenant de Phusion Passenger. Cela ne semble pas correspondre à une installation Discourse normale :thinking:.

23

J’ai désactivé Discourse car, en raison du problème de suppression, il était inutilisable. Maintenant, une autre application répond à cette URL.

24

Ah, je vois. Puisque le problème ne peut pas être reproduit sur une nouvelle installation, je dirais que nous pouvons clore ce sujet. Si le problème se reproduit, veuillez ouvrir un nouveau sujet en décrivant les étapes de reproduction.

2 « J'aime »
25

@Falco Je l’ai remis en ligne sur http://discourse.apicolturaitalianafb.it/ et tu peux essayer, installation standard en suivant la documentation ici.

La commande curl renvoie une erreur CSRF, et apparaît immédiatement dans le journal interne nginx de Discourse, mais les suppressions via l’interface ne fonctionnent toujours pas et n’apparaissent dans le journal qu’avec un délai d’environ 35 secondes, comme dans la vidéo que j’ai envoyée.

Si je mets discourse.apicolturaitalianafb.it:8880 comme nom d’hôte dans app.yml, que je reconstruis et que je vais sur http://discourse.apicolturaitalianafb.it:8880, cela fonctionne normalement, mais je ne peux pas l’utiliser ainsi.

Ayant Apache qui exécute un site web en production, j’ai essayé de le placer derrière haproxy comme indiqué dans la documentation de ce site, et les suppressions depuis Discourse cessent de fonctionner, mais ta commande curl fonctionne. J’ai aussi essayé un proxy inverse Apache : curl fonctionne, mais les suppressions depuis Discourse non. J’ai essayé de configurer Discourse pour fonctionner via un socket Unix et de faire un proxy inverse vers celui-ci, mais le problème est le même.

Pour moi, la preuve est que le proxy inverse ne « tue » pas les suppressions, mais que les scripts JavaScript de Discourse, pour une raison quelconque, cessent d’exécuter correctement les suppressions HTML.

Ton installation fraîche que tu as essayée était-elle directement exposée ?