Trabajos fallidos por correo electrónico

Hola

Discourse build: 3.5.0.beta2-dev (176ee0bf60)
Alojado en: VPS - Centminmod (131.00stable) en Alma8
Incidencia: El correo falla periódicamente

Tengo dos vHosts en este VPS. Uno con Xenforo, otro con Discourse.

Mis hosts Xenforo envían correos felizmente 24/7 sin problemas. Sin embargo, Discourse parece fallar aproximadamente cada ~24 horas con el mensaje “Hay [número que aumenta] trabajos de correo que han fallado. Comprueba tu app.yml y asegúrate de que la configuración del servidor de correo sea correcta. Consulta los trabajos fallidos en Sidekiq”.

Puedo “resolver” el problema temporalmente reiniciando el servicio docker. El flujo de correo se reanuda.
Estoy seguro de que la configuración del correo es correcta. Una vez que se reinicia el servicio docker, puedo ir a admin – > correo – > configuración del servidor y registros – > configuración y enviar un correo.

Una vez que falla, no puedo.

Estoy viendo muchos mensajes de que Sidekiq consume demasiada memoria (usando 5xxM) para reiniciar 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'

También puedo ver Excepción de trabajo: no hay dirección para 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' 

No he cambiado mucho la configuración de este servidor en cuanto a docker. He actualizado el kernel / php y otros servicios que están fuera de este docker.
El problema se ha vuelto más frecuente recientemente desde que actualicé la compilación de discourse. Era estable antes.
Tengo 8.8.8.8 y 8.8.4.4 como DNS.

¡Cualquier indicación sería apreciada!

Si Sidekiq consume demasiada memoria, puede hacer que Discourse se reinicie, lo que puede interrumpir los trabajos de correo electrónico programados. Discourse incluye una función de reinicio automático si el uso de memoria de Sidekiq supera un umbral definido.

Para abordar esto, verifique la configuración UNICORN_SIDEKIQ_MAX_RSS en su archivo app.yml. Si el valor es demasiado bajo, considere aumentarlo.

Para más discusiones sobre este problema, puede consultar este tema:
Sidekiq está consumiendo demasiada memoria - reiniciando.

2 Me gusta

Ajustaré esa configuración ahora y revertiré si sigo teniendo estos problemas.

1 me gusta

Urgh, poco más de 24 horas después y he fallado el correo electrónico…

Jobs::HandledExceptionWrapper: Wrapped Net::OpenTimeout: execution expired
1 me gusta

Asegúrate de que el servidor SMTP sea accesible desde tu instancia de Discourse
telnet DISCOURSE_SMTP_ADDRESS DISCOURSE_SMTP_PORT

1 me gusta

Esperaré al fallo nuevamente y reintentaré.

Tengo una instalación de XenForo sin Docker en el mismo VPS y no presenta problemas.

Informaré los resultados. Aprecio mucho tu orientación hasta ahora.

2 Me gusta

Puedo acceder al servidor smtp.

2 Me gusta

Tuve un par de fallos seguidos y luego nada durante unas 8 horas.

1 me gusta