Problema grave con l'email da l'ultimo aggiornamento di alcuni giorni fa - 3.4.0.beta4-dev

Supporto
24

Con un piccolo campione di nuovi argomenti osservati e risposte via email a tali argomenti, sembra promettente, i conteggi delle email sono per lo più corretti finora. Questo è quello che ho fatto e non so se ha risolto il problema o meno, ma finora sembra meglio, ora:

Ho aggiornato a 3.5.0.beta1-dev, forzato il nameserver DNS a 8.8.8.8 (da 1.1.1.1) e riavviato.

Ho notato questo:
docker image list --all

REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/app latest 32adad867562 6 ore fa 3.68GB
none none 5306688e5dcb 9 giorni fa 2.74GB

ma nel tempo è cambiato in, senza che io facessi nulla, in:

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

quindi, non sono sicuro di cosa fosse quel “none”

Terrò d’occhio questo e riporterò dopo aver valutato più dati.

Vedo alcuni errori di connessione a redis e errori nginx / postgres che indagherò anche:

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:
Guardando questo: 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/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/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/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
26

Confermato: il grave problema delle email sembra risolto da quando ho aggiornato alla versione 3.5.0.beta1-dev, ho forzato il nameserver DNS a 8.8.8.8 (da 1.1.1.1) e ho riavviato.

Ho anche esteso l’open_timeout SMTP a 15, ma probabilmente non era necessario, tuttavia non ho intenzione di riportarlo al valore predefinito di 5.

4 Mi Piace
27

Felice di sentire che è stato risolto, le configurazioni DNS sono la causa principale del 78% di tutti i problemi nel mondo dei sysadmin.

3 Mi Piace
28

Ho alcuni nuovi problemi con l’invio di email che sono iniziati negli ultimi 4 giorni. Non sono sicuro se sia meglio continuare questo thread o iniziarne uno nuovo, ma per ora continuerò questo.

Recentemente ho eseguito un aggiornamento completo del sito dalla riga di comando, più o meno nel momento in cui si è verificato questo problema.

  • Nessun utente riceve email di notifica sull’attività del sito.
  • L’invio SMTP sembra funzionare bene, un test di recapito email è stato superato istantaneamente.
  • Sidekiq mostra migliaia di job accodati che vengono ritentati regolarmente ma falliscono costantemente. (Oltre 7000 job accodati)
  • I log mostrano un errore molto evidente e numeroso Job exception: UserDestroyer::PostsExistError - Ho cercato questo su Meta ma nessuno ha avuto problemi simili almeno dal 2017, quando l’ultimo argomento lo menzionava. (Oltre 9000 errori, tutti negli ultimi 4 giorni)
Stack trace completo dai log 
/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'

Qualcuno ha consigli su come procedere con il debug?

29

Ok, solo per aggiornare: l’unica altra cosa che mi è venuta in mente da fare è stata git pull; ./launcher rebuild app che ho appena eseguito e sembra aver risolto il problema, le email vengono ora inviate e il backlog di Sidekiq di lavori email accodati sta iniziando a diminuire.

Riesaminando i commit in discourse/discourse degli ultimi giorni, non sono sicuro di cosa l’abbia risolto. Ma se qualcuno vuole indagare ulteriormente, sono felice di fornire ulteriori informazioni se necessario.

5 Mi Piace
30

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