Email per lavori falliti

Ciao!

Build di Discourse: 3.5.0.beta2-dev(176ee0bf60)
Ospitato su: VPS - Centminmod (131.00stable) su Alma8
Problema: Invio email che fallisce periodicamente

Ho due vHost su questo VPS. Uno con Xenforo, uno con Discourse.

Il mio Xenforo invia felicemente email 24 ore su 24, 7 giorni su 7, senza problemi. Discourse, tuttavia, sembra fallire ogni ~24 ore circa con il messaggio “Ci sono [numero che aumenta] processi email che sono falliti. Controlla il tuo app.yml e assicurati che le impostazioni del server di posta siano corrette. Vedi i processi falliti in Sidekiq.”

Posso “risolvere” temporaneamente il problema riavviando il servizio docker. Il flusso di posta riprende.
Sono sicuro che le impostazioni di posta siano corrette. Una volta riavviato il servizio docker, posso visitare admin –> email –> configurazione server e log –> impostazioni e inviare un’email.

Una volta che fallisce, non posso.

Vedo molti messaggi di Sidekiq che consuma troppa memoria (utilizzando 5xxM) per il riavvio di Fastserver-app

activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `block in warn'
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `each'
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch'
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `warn'
/var/www/discourse/lib/demon/sidekiq.rb:55:in `block in rss_memory_check'
/var/www/discourse/lib/demon/sidekiq.rb:49:in `each'
/var/www/discourse/lib/demon/sidekiq.rb:49:in `rss_memory_check'
config/unicorn.conf.rb:132:in `block (2 levels) in reload'

Posso anche vedere l’eccezione del processo: nessun indirizzo per meta.discourse.org (ResolvError)

excon-1.2.4/lib/excon/socket.rb:191:in `connect'
excon-1.2.4/lib/excon/ssl_socket.rb:194:in `connect'
excon-1.2.4/lib/excon/socket.rb:60:in `initialize'
excon-1.2.4/lib/excon/ssl_socket.rb:10:in `initialize'
excon-1.2.4/lib/excon/connection.rb:487:in `new'
excon-1.2.4/lib/excon/connection.rb:487:in `socket'
excon-1.2.4/lib/excon/connection.rb:120:in `request_call'
excon-1.2.4/lib/excon/middlewares/mock.rb:57:in `request_call'
excon-1.2.4/lib/excon/middlewares/instrumentor.rb:34:in `request_call'
excon-1.2.4/lib/excon/middlewares/idempotent.rb:19:in `request_call'
excon-1.2.4/lib/excon/middlewares/base.rb:22:in `request_call'
excon-1.2.4/lib/excon/middlewares/decompress.rb:14:in `request_call'
excon-1.2.4/lib/excon/middlewares/base.rb:22:in `request_call'
excon-1.2.4/lib/excon/connection.rb:293:in `request'
/var/www/discourse/lib/discourse_updates.rb:136:in `new_features_payload'
/var/www/discourse/app/jobs/scheduled/check_new_features.rb:24: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'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'

Non ho cambiato molto sulla configurazione di questo server per un po’ di tempo riguardo a docker. Ho aggiornato il kernel / php e altri servizi esterni a questo docker.
Il problema è diventato più frequente di recente da quando ho aggiornato la build di discourse. Prima era stabile.

Ho 8.8.8.8 e 8.8.4.4 come DNS.

Qualsiasi suggerimento sarebbe apprezzato!

Se Sidekiq consuma troppa memoria, può causare il riavvio di Discourse, il che potrebbe interrompere i processi email pianificati. Discourse include una funzione di riavvio automatico se l’utilizzo della memoria di Sidekiq supera una soglia definita.

Per risolvere questo problema, controlla l’impostazione UNICORN_SIDEKIQ_MAX_RSS nel tuo file app.yml. Se il valore è troppo basso, considera di aumentarlo.

Per ulteriori discussioni su questo problema, puoi fare riferimento a questo argomento:
Sidekiq sta consumando troppa memoria - riavvio.

2 Mi Piace

Regolerò quell’impostazione ora e tornerò indietro se continuerò ad avere questi problemi.

1 Mi Piace

Urgh, sono passate poco più di 24 ore e ho fallito l’email…

Jobs::HandledExceptionWrapper: Wrapped Net::OpenTimeout: execution expired
1 Mi Piace

Assicurati che il server SMTP sia raggiungibile dalla tua istanza di discourse
telnet DISCOURSE_SMTP_ADDRESS DISCOURSE_SMTP_PORT

1 Mi Piace

Aspetterò di nuovo il fallimento e riproverò.

Ho un’installazione di XenForo non in Docker sullo stesso VPS e non dà nessun problema.

Riporterò i risultati. Apprezzo la tua guida finora.

2 Mi Piace

Riesco a raggiungere il server smtp.

2 Mi Piace

Ho avuto un paio di fallimenti in rapida successione, poi niente per circa 8 ore ora

1 Mi Piace