Wir haben von einer Mailingliste migriert, und viele Nutzer nutzen unser Forum nach wie vor hauptsächlich per E-Mail.
Etwa 300 Nutzer befinden sich im Mailinglisten-Modus. Doch Discourse scheint bei einem neuen Thema nur etwa 75 bis 80 E-Mails zu versenden.
Ich habe die Mailinglisten-Einstellungen verschiedener Mitglieder verglichen, und diese sind identisch.
Im Abschnitt „Übersprungen“ findet sich nichts.
Ich weiß nicht, wo ich nach möglichen Ursachen suchen soll.
Sind alle Benutzer aktiviert? Vielleicht erhalten sie keine E-Mails?
Ja, das sind alle aktiviert.
Leider scheint es auch zufällig zu sein; ich habe einige Konten, die ich zur Einrichtung verwende, und diese verhalten sich ebenfalls unterschiedlich.
Ich habe mir jetzt ein paar ältere Themen hier angesehen, und das scheint ähnlich zu sein: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
Es könnte dasselbe Problem sein. Allerdings weiß ich nicht, wie ich die Einstellungen ändern soll, wie in der Lösung dieses Beitrags vorgeschlagen.
Ich versuche Folgendes auszuführen:
User.find_by_username(‘Neuer.test’).mailing_list_mode
erhalte aber:
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
Der Modus für Mailinglisten ist in der Tabelle user_options gespeichert. Versuche stattdessen, UserOption.where(mailing_list_mode: true) auszuführen. Um die Benutzer-IDs aller Benutzer zu erhalten, bei denen der Modus für Mailinglisten aktiviert ist, führe UserOption.where(mailing_list_mode: true).pluck(:user_id) aus.
Vielen Dank, @simon
Ich habe, wie in deinem Beitrag vorgeschlagen, eine Liste generiert. Tatsächlich sind es mehrere Listen. Es wird eine Liste mit Benutzer-IDs erstellt, und sobald etwa 50 erreicht sind, erscheint :...skipping..., danach beginnt es erneut mit denselben Benutzer-IDs, fügt am Ende eine neue hinzu und wiederholt dies etwa 4- oder 5-mal. Dazwischen gibt es einen ganzen Abschnitt mit nur leeren Zeilen. Das könnte aber normales Verhalten sein?
In jedem Fall ist dies bei weitem keine vollständige Liste der Benutzer, die über den E-Mail-Listen-Modus abonniert sind (nur 58, ich erwarte etwa 350).
Anschließend habe ich einige Prüfungen an den IDs durchgeführt, und keine davon hat beispielsweise den letzten Beitrag erhalten.
Ich habe auch UserOption.where(mailing_list_mode: false).pluck(:user_id) ausgeführt, was weitere 29 Einträge ergab.
Die Ausführung von UserOption.where(mailing_list_mode: 1).pluck(:user_id) ergab eine ähnliche Anzahl wie bei true und dieselben Benutzer.
Insgesamt habe ich nur etwa 90 der 400 aktivierten Benutzer gefunden. Alles sehr seltsam, und ich verstehe nicht, was hier vor sich geht.
Jede Hilfe wäre sehr willkommen.
P.S. Wie beende ich die Suche nach dem letzten : am Ende der Suchergebnisse, damit ich eine weitere Abfrage ausführen kann?
Wenn die Abfrage mehr Text zurückgibt, als auf den Bildschirm passt, wird er mit weniger dargestellt. Du kannst im Internet nach der Funktionsweise suchen.
Die Leertaste wechselt zum nächsten Bildschirm, / sucht, q beendet.
Ich denke also, es klingt so, als würden Mails an die aktiven Benutzer zugestellt. Die anderen sind vielleicht inaktiv?
Danke, Jay.
Nein, wir haben über 450 aktive Benutzer. Ich kann kein Muster erkennen. Ich habe einen früheren Beitrag von vor ein paar Tagen angesehen, der im E-Mail-Listen-Modus an 334 Benutzer gesendet wurde.
Das Einzige, was sich seitdem geändert hat, war, dass wir einen SPF-Eintrag zu unserem DNS hinzugefügt haben, da wir Probleme beim Senden an Google hatten. Das betraf jedoch unseren Mailserver; ich habe keine SMTP-Einstellungen in Discourse geändert.
@pfaffman Ich habe Data Explorer gerade installiert. Vielleicht kann ich dort stattdessen eine Abfrage ausführen?
Das bringt mich langsam zur Verzweiflung 
Ich wollte gerade posten, dass sich irgendwie alles „von selbst geregelt
Das Problem scheint ein Fehler 421.4.7.0 zu sein: zu viele Verbindungen von dieser IP-Adresse.
Seltsamerweise tritt dies hauptsächlich bei einem Mitglied auf.
Wie kann ich das beheben?
Hier ist, was die Protokolle sagen:
Nachricht (1957 gemeldete Kopien)
Job-Ausnahme: 421 4.7.0 dd27022.xxxxxx.com Fehler: zu viele Verbindungen von xxx.xxx.xx.xxx
### Rückverfolgung
/usr/local/lib/ruby/2.6.0/net/smtp.rb:969:in `check_response'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.1/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.1/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now'
actionmailer-6.0.1/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:113:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:212:in `send'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:90:in `block (2 levels) in execute'
/var/www/discourse/app/models/email_log.rb:35:in `block in unique_email_per_post'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/email_log.rb:31:in `unique_email_per_post'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:89:in `block in execute'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:238:in `block in in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `loop'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:135:in `find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:69:in `find_each'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:61:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.4/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.4/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.4/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.4/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.4/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.4/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.4/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.4/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.4/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.4/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.4/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.4/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.4/lib/sidekiq/util.rb:24:in `block in safe_thread'
Sie müssen sich an Ihren E-Mail-Anbieter wenden, das hat nichts mit Discourse zu tun.
@codinghorror
Ich habe also meinen E-Mail-Anbieter gewechselt und versende jetzt über Amazon SES. Das schien es für ein paar Wochen gelöst zu haben. Jetzt hat Discourse wieder angefangen, das Versenden von E-Mails mitten in der Zustellung an Abonnenten einer Mailingliste zufällig abzubrechen. Keine Fehler in den Logs. Ich habe den Container neu erstellt, und bisher scheint es wieder in Ordnung zu sein. Gibt es sonst noch einen Ort, an dem ich nach potenziellen Fehlerprotokollen suchen kann?
Gibt es Aufgaben, die in Sidekiq hängen?
Nein, leider nicht.
Ich habe in den letzten Tagen ein ähnliches Problem. E-Mails werden nicht an Mailinglisten-Nutzer gesendet, es hängen keine Jobs in Sidekiq fest, und ich erhalte denselben Fehler im Log. Ich habe bereits versucht, das System neu aufzusetzen, aber das scheint keine Veränderung zu bewirken. Das bereitet unseren Nutzern wirklich große Sorgen.
Anscheinend passiert Folgendes: Nach einem Neustart wird eine neue Nachricht gesendet, aber danach werden keine weiteren Beiträge oder Antworten mehr versendet.
Jede Hilfe wäre sehr willkommen!
Ed
Das entwickelt sich für mich zu einem wirklich frustrierenden Problem.
Heute hat Discourse beschlossen, die E-Mail-Versendung an die Mailing-Liste-Abonnenten nach nur 15 gesendeten E-Mails einzustellen. Es liegt kein Problem beim Anbieter vor, da ich diesen bereits gewechselt habe. Auch gibt es keine Fehlermeldungen im Log oder etwas, das in Sidekiq hängen geblieben ist.
Ich glaube, der einzige Ausweg scheint ein Rebuild zu sein.
Gibt es eine Möglichkeit, einen Rebuild automatisch in einem bestimmten Zeitintervall zu planen? Dann müsste ich es wenigstens nicht ständig überwachen.
Du könntest einen Cron-Job einrichten, um das zu erledigen.
Hast du bei einigen Benutzern das tägliche Maximum an E-Mails nicht erreicht? Haben sie E-Mails nicht deaktiviert? (Das würde nicht erklären, warum ein Neuaufbau etwas beheben würde). Hast du genügend RAM? Steht nichts in den Logs?
out of memory ist eine ziemlich klare Fehlermeldung.
EDIT: Ups. Ich habe dich mit einem anderen Thema verwechselt, also mag das Ganze über Multisite, obwohl alles zutrifft, hier vielleicht keinen Sinn ergeben.
Ich bin mir ziemlich sicher, dass meine nur für Multisite bestimmte Instanz mit 4 GB RAM läuft, aber darauf laufen auch keine MySQL-, Apache- und WordPress-Dienste. Meine Site mit (staging + production)*(discourse + wordpress) hat mir zuvor Kopfzerbrechen bereitet, bevor ich sie auf 8 GB hochgestuft habe. Dazu gehören Container für PostgreSQL, Redis, Traefik, Prometheus und MariaDB sowie je zwei für WordPress und Discourse (kein Multisite, da Staging andere Plugins als Production benötigen kann).
Wenn es dir darum geht, Geld zu sparen und du Discourse-Sites mit geringem Verkehr hast, ist es wahrscheinlich am besten, jede Site auf einem separaten $5-Droplet (1 GB) zu betreiben.
Ja, das habe ich mir gedacht 
Ich nutze eine Standard-Shared-CPU und betreibe nur eine Discourse-Seite auf meinem Droplet.