E-mails des travaux échoués

Soutien
1

Bonjour !

Version de Discourse : 3.5.0.beta2-dev(176ee0bf60)
Hébergé sur : VPS - Centminmod (131.00stable) sur Alma8
Problème : L’envoi d’e-mails échoue périodiquement

J’ai deux vHosts sur ce VPS. Un avec Xenforo, un avec Discourse.

Mon hôte Xenforo envoie joyeusement des e-mails 24h/24 et 7j/7 sans problème. Cependant, Discourse semble échouer environ toutes les 24 heures avec le message “Il y a [nombre qui augmente] tâches d’e-mail qui ont échoué. Vérifiez votre app.yml et assurez-vous que les paramètres du serveur de messagerie sont corrects. Consultez les tâches échouées dans Sidekiq.”

Je peux “résoudre” le problème temporairement en redémarrant le service docker. Le flux de courrier reprend.
Je suis sûr que les paramètres de messagerie sont corrects. Une fois le service docker redémarré, je peux aller dans admin –> email –> configuration du serveur & journaux –> paramètres et envoyer un e-mail.

Une fois qu’il échoue, je ne peux plus le faire.

Je constate que Sidekiq consomme trop de mémoire (utilisant 5xxM) pour le redémarrage de 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'

Je vois aussi une exception de tâche : pas d’adresse pour 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'

Je n’ai pas beaucoup changé la configuration de ce serveur concernant docker depuis un certain temps. J’ai mis à jour le noyau / php et d’autres services qui sont en dehors de ce docker.
Le problème est devenu plus fréquent récemment depuis que j’ai mis à jour la version de Discourse. C’était stable avant.
J’ai 8.8.8.8 et 8.8.4.4 comme DNS.

Toute piste serait appréciée !

2

Si Sidekiq consomme trop de mémoire, cela peut entraîner le redémarrage de Discourse, ce qui peut interrompre les tâches d’e-mail planifiées. Discourse inclut une fonctionnalité de redémarrage automatique si l’utilisation de la mémoire de Sidekiq dépasse un seuil défini.

Pour résoudre ce problème, vérifiez le paramètre UNICORN_SIDEKIQ_MAX_RSS dans votre fichier app.yml. Si la valeur est trop basse, envisagez de l’augmenter.

Pour plus de discussions sur ce problème, vous pouvez vous référer à ce sujet :
Sidekiq consomme trop de mémoire - redémarrage.

2 « J'aime »
3

J’ajusterai ce paramètre maintenant et je reviendrai si je continue à avoir ces problèmes.

1 « J'aime »
4

Urgh, un peu plus de 24 heures plus tard et j’ai échoué à l’e-mail…

Jobs::HandledExceptionWrapper : Net::OpenTimeout encapsulé : délai d'exécution expiré
1 « J'aime »
5

Assurez-vous que le serveur SMTP est accessible depuis votre instance Discourse
telnet DISCOURSE_SMTP_ADDRESS DISCOURSE_SMTP_PORT

1 « J'aime »
6

Je vais attendre à nouveau l’échec et réessayer.

J’ai une installation XenForo non Docker sur le même VPS et elle ne se plaint pas.

Je ferai un retour. J’apprécie votre aide jusqu’à présent.

2 « J'aime »
7

Je peux accéder au serveur smtp.

2 « J'aime »
8

J’ai eu quelques échecs en succession rapide, puis rien pendant environ 8 heures maintenant.

1 « J'aime »