E-Mail-gescheiterte Jobs

Hallo!

Discourse Build: 3.5.0.beta2-dev(176ee0bf60)
Gehostet auf: VPS - Centminmod (131.00stable) auf Alma8
Problem: E-Mails schlagen periodisch fehl

Ich habe zwei vHosts auf diesem VPS. Einer mit XenForo, einer mit Discourse.

Meine XenForo-Hosts senden problemlos 24/7 E-Mails. Der Discourse scheint jedoch etwa alle 24 Stunden mit der Meldung “Es gibt [Zahl, die steigt] fehlgeschlagene E-Mail-Jobs. Überprüfen Sie Ihre app.yml und stellen Sie sicher, dass die Mailserver-Einstellungen korrekt sind. Sehen Sie sich die fehlgeschlagenen Jobs in Sidekiq an.” auszufallen.

Ich kann das Problem vorübergehend lösen, indem ich den Docker-Dienst neu starte. Der Mail-Fluss wird wieder aufgenommen.
Ich bin sicher, dass die Mail-Einstellungen korrekt sind. Sobald der Docker-Dienst neu gestartet ist, kann ich zu Admin → E-Mail → Server-Setup & Protokolle → Einstellungen navigieren und eine E-Mail versenden.

Sobald es fehlschlägt, kann ich das nicht mehr.

Ich sehe viele Meldungen, dass Sidekiq zu viel Speicher verbraucht (verwendet 5xxM) für Fastserver-App-Neustarts

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'

Ich sehe auch Job-Ausnahme: keine Adresse für 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'

Ich habe die Konfiguration dieses Servers in Bezug auf Docker seit einiger Zeit nicht wesentlich geändert. Ich habe den Kernel, PHP und andere Dienste außerhalb dieses Docker aktualisiert.

Das Problem ist in letzter Zeit häufiger aufgetreten, seit ich den Discourse-Build aktualisiert habe. Zuvor war er stabil.

Ich habe 8.8.8.8 und 8.8.4.4 als DNS.

Jeder Hinweis wäre willkommen!

Wenn Sidekiq zu viel Speicher verbraucht, kann dies dazu führen, dass Discourse neu startet, was geplante E-Mail-Aufträge unterbrechen kann. Discourse verfügt über eine automatische Neustartfunktion, falls die Speichernutzung von Sidekiq einen definierten Schwellenwert überschreitet.

Um dies zu beheben, überprüfen Sie die Einstellung UNICORN_SIDEKIQ_MAX_RSS in Ihrer app.yml-Datei. Wenn der Wert zu niedrig ist, sollten Sie ihn erhöhen.

Für weitere Diskussionen zu diesem Thema können Sie sich auf diesen Thread beziehen:
Sidekiq verbraucht zu viel Speicher – Neustart.

2 „Gefällt mir“

Ich werde diese Einstellung jetzt anpassen und mich melden, wenn ich weiterhin Probleme habe.

1 „Gefällt mir“

Igitt, etwas mehr als 24 Stunden später und ich habe die E-Mail nicht geschafft …

Jobs::HandledExceptionWrapper: Wrapped Net::OpenTimeout: execution expired
1 „Gefällt mir“

Stellen Sie sicher, dass der SMTP-Server von Ihrer Discourse-Instanz erreichbar ist
telnet DISCOURSE_SMTP_ADDRESS DISCOURSE_SMTP_PORT

1 „Gefällt mir“

Ich werde wieder auf den Fehler warten und es erneut versuchen.

Ich habe eine XenForo-Installation ohne Docker auf demselben VPS und es gibt keine Beschwerden.

Ich werde mich melden. Ich schätze Ihre bisherige Unterstützung.

2 „Gefällt mir“

Ich kann den SMTP-Server erreichen.

2 „Gefällt mir“

Nachdem es kurz hintereinander zu einigen Ausfällen kam, passierte etwa 8 Stunden lang nichts mehr.

1 „Gefällt mir“