Problème grave avec les emails depuis la dernière mise à jour il y a quelques jours - 3.4.0.beta4-dev

Soutien
24

Avec un petit échantillon de nouveaux sujets suivis et de réponses par e-mail à ces sujets, cela semble prometteur, les décomptes d’e-mails sont pour la plupart corrects jusqu’à présent. Voici ce que j’ai fait et je ne sais pas si cela a résolu le problème ou non, mais jusqu’à présent, cela semble mieux, maintenant :

J’ai mis à niveau vers la version 3.5.0.beta1-dev, forcé le serveur DNS à utiliser 8.8.8.8 (depuis 1.1.1.1) et redémarré.

J’ai noté ceci :
docker image list --all

REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/app latest 32adad867562 6 hours ago 3.68GB
none none 5306688e5dcb 9 days ago 2.74GB

mais avec le temps, cela a changé, sans que je fasse quoi que ce soit, pour :

REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/app latest 32adad867562 26 hours ago 3.68GB
discourse/base 2.0.20250129-0720 5306688e5dcb 10 days ago 2.74GB

donc, je ne suis pas sûr de ce que signifiait ce « none ».

Je vais garder un œil là-dessus et je ferai un rapport après avoir évalué davantage de données.

Je vois des erreurs de connexion redis et des erreurs nginx / postgres que je vais également examiner :

nginx :

2606 upstream prematurely closed connection while reading response header from upstream

redis :

Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
heartbeat: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
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'
Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)

postgres :

current:2025-02-08 04:24:06.133 UTC [75838] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_post_reply_keys_on_user_id_and_post_id"
current:2025-02-08 04:24:20.624 UTC [75838] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_post_reply_keys_on_user_id_and_post_id"
current:2025-02-08 08:05:19.485 UTC [91041] discourse@discourse LOG:  duration: 2345.289 ms  statement: COPY public.scheduler_stats (id, name, hostname, pid, duration_ms, live_slots_start, live_slots_finish, started_at, success, error) TO stdout;

/log - Job exception: execution expired :
En regardant ceci : SMTP Net::ReadTimeout without relation to net or login problems - SMTP host is just slow - #2 by Falco

Message (3 copies reported)

Job exception: execution expired

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:663:in `initialize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:663:in `open'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:663:in `tcp_socket'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:672:in `block in do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:671:in `do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:642:in `start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/6.5.12/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
26

Confirmé : Le problème grave d’e-mail semble résolu depuis que j’ai mis à niveau vers 3.5.0.beta1-dev, forcé le serveur DNS à 8.8.8.8 (depuis 1.1.1.1) et redémarré.

J’ai également étendu le délai d’attente SMTP open_timeout à 15, mais ce n’est probablement pas nécessaire, mais je n’ai pas l’intention de le remettre à la valeur par défaut de 5.

4 « J'aime »
27

Heureux d’apprendre que c’est résolu, les configurations DNS sont à la racine de 78 % de tous les problèmes dans le monde de l’administration système.

3 « J'aime »
28

J’ai de nouveaux problèmes avec l’envoi d’e-mails qui ont commencé il y a 4 jours. Je ne sais pas s’il vaut mieux continuer sur ce fil de discussion ou en commencer un nouveau, mais pour l’instant, je vais continuer sur celui-ci.

J’avais récemment effectué une mise à jour complète du site en ligne via la ligne de commande, à peu près au moment où ce problème est survenu.

  • Aucun utilisateur ne reçoit d’e-mails de notification concernant l’activité sur le site.
  • L’envoi SMTP semble fonctionner correctement, un test de délivrabilité des e-mails a fonctionné instantanément.
  • Sidekiq affiche des milliers de tâches mises en file d’attente qui sont régulièrement retentées mais échouent systématiquement. (Plus de 7000 tâches en file d’attente)
  • Les journaux montrent une erreur très prédominante et nombreuse : Job exception: UserDestroyer::PostsExistError - J’ai cherché cela sur Meta, mais personne d’autre n’a eu de problèmes similaires depuis au moins 2017, date du dernier sujet qui en parlait. (Plus de 9000 erreurs, toutes survenues au cours des 4 derniers jours)
Full stacktrace from logs 
/var/www/discourse/app/services/user_destroyer.rb:18:in `destroy'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:23:in `block (2 levels) in execute_onceoff'
activerecord-7.2.2.1/lib/active_record/relation/delegation.rb:98:in `each'
activerecord-7.2.2.1/lib/active_record/relation/delegation.rb:98:in `each'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:21:in `block in execute_onceoff'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:14:in `each_key'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:14:in `execute_onceoff'
/var/www/discourse/app/jobs/onceoff/onceoff.rb:35:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'

Quelqu’un aurait-il des conseils sur la manière de déboguer et de procéder ?

29

Ok, juste pour vous tenir au courant : la seule chose supplémentaire à laquelle j’ai pu penser était de faire git pull; ./launcher rebuild app, ce que je viens de faire et cela semble avoir résolu le problème. Les e-mails sont maintenant envoyés et le backlog Sidekiq des tâches d’e-mails mises en file d’attente commence à diminuer.

En examinant les commits dans discourse/discourse au cours des derniers jours, je ne suis pas sûr de ce qui l’a résolu. Mais si quelqu’un souhaite enquêter davantage, je suis heureux de fournir plus d’informations si nécessaire.

5 « J'aime »
30

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