We have migrated from a Mailing List and lot of users are still using our forum predominately via Email.
There are about 300 that are in Mailing List mode. But Discourse only seems to send out around 75 to 80 Mails when a new topic is added.
I compared various members MailingList User settings and they are the same.
There is nothing in the skipped section.
I don’t know where to look for might be causing this.
1 Like
Are all of the user’s activated? Maybe they aren’t getting any mail?
Yes, that are all activated.
It also seems random unfortunately, I have a few accounts I use for setting stuff and they behave differently too.
Now I looked at a few older topics on here and this seems similar: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
Might be the same Problem. However I don’t know how to change the settings as suggested in the solution on that post.
I am trying to run this:
User.find_by_username(‘Neuer.test’).mailing_list_mode
but get:
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
Mailing list mode is set on the user_options table. Try running UserOption.where(mailing_list_mode: true). To get the user ids of all users with mailing list mode enabled, run UserOption.where(mailing_list_mode: true).pluck(:user_id)
5 Likes
Thank you @simon
I generated a list as suggested in your post. It’s actually a number of lists. It generates a User ID list and then gets to about 50 and says :...skipping... and then starts again with the same User IDs, adding a new one at the bottom and repeating this about 4 or 5 times… In between there is a whole section of just blank lines. But that might be normal behaviour?
In any case, this is nowhere near a complete list of users subscribed via Mailing List Mode (only 58, I am expecting around 350)
I then ran a few checks on the IDs and none of them received the last posting for example.
I also ran UserOption.where(mailing_list_mode: false).pluck(:user_id) which came up with another 29 entries.
Running UserOption.where(mailing_list_mode: 1).pluck(:user_id) came up with a similar Number to true and the same users.
All told. I only found about 90 of the 400, activated User. All very strange and I don’t understand what is going on.
Any help much appreciated.
P.s. How do I exit after the last : at the bottom of the search results, so I can run another query?
1 Like
When the query returns more text than will fit in the screen it displays it with less. You can google for how it works.
Space will go to the next screen, / will search, q will quit.
So I think it sounds like you’re getting mail delivered to the active users. The others might be inactive?
1 Like
Thanks Jay.
No, we have over 450 active users. I can’t really see a pattern I looked at an earlier post from a few days ago and that went out to 334 Users via Mailing List mode.
The only thing that has changed since, was that we added a SPF Record to our DNS as we were having trouble sending to google. But that was on our mail server, I didn’t alter any of the SMTP settings in Discourse.
@pfaffman I have just installed Data Explorer, maybe there is a query I can run there instead?
This is starting to do my head in 
I was going to post, that somehow everything seemed to have ‘worked itself out’ as 336 people received various recent posts.
Then came two answers to a post in quick succession, both by the same user. 181 members received both messages, 38 received one message leaving 117 without any E-mails.
Is there any other log somewhere i could look at that might shed some light onto this? There is nothing is sidekiq.
The problem appears to be a 421.4.7.0 Error too many connections from IP Address.
Oddly it seems to happen mainly with one Member.
How can I fix this?
Here is what Logs says:
Message (1957 copies reported)
Job exception: 421 4.7.0 dd27022.xxxxxx.com Error: too many connections from xxx.xxx.xx.xxx
### Backtrace
/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'You will have to inquire with your email provider, it doesn’t have anything to do with Discourse.
1 Like
@codinghorror
So I changed email provider and I am now sending via Amazon SES. This seemed to have solved it for a few weeks. Now Discourse has started randomly stopping the mail sending midway through a delivery to mailing list subscribers again. No errors in the logs. I have rebuild the container and for now it seems ok again. Anywhere else I can look for a potential error log?
Are there tasks held up in sidekiq?
No, there aren’t unfortunately.
1 Like
I’m having a similar issue over the last few days. Emails not being sent out to mailing list users, no jobs held up in Sidekiq, and getting the same log error. I’ve tried rebuilding but doesn’t seem to make a difference. This is really causing a lot of anguish for our users.
What seems to happen is that after a rebuild, if a new post is received, it gets sent out, but after that no subsequent posts/replies are sent.
Any help would be much appreciated!
Ed
This is turning into a really frustrating issue for me.
Today Discourse decided to stop sending to Mailing List subscribers after just delivering 15 emails. It is not a provider issue as I have already changed providers. There also no error messages in the log or anything held up in sidekiq.
I think the only way around it seems to be a rebuild.
Is there anyway I can automatically schedule a rebuild for a given time interval? At least then I don’t have to constantly monitor it.
You could set up a cron job to do that.
You’ve not hit the max emails per day for some users? They haven’t disabled emails? (that wouldn’t explain why a rebuild would fix anything). You have enough ram? Nothing in the logs?
1 Like
out of memory is a pretty clear error message.
EDIT: Ooops. I confused you with another topic, so this stuff about multisite, while all true, may not make any sense here.
I’m pretty sure that my multisite-only instance is running with 4GB of RAM, but that doesn’t also have mysql and apache and wordpress running. My site with (staging + production)*(discourse + wordpress) gave me fits before bumping it to 8GB. That includes containers for postgres, redis, traefik, prometheus, and mariadb plus 2 each for WP and Discourse (not multisite since staging needs to be able to have different plugins from production).
If saving money is your game and yo have low volume Discourse sites, each one on a separate $5(1GB) droplet is probably the way to go.
1 Like
Yes, I figured 
I am on a standard shared CPU and only running one Discourse site on my droplet.