It’s Problem with your mail server. I think it’s the case that these errors are reported now. It’s probably not a new problem. They’ll get sent when sidekiq tries again.
Any other solution?
The count on Sidekiq has gone up to 41 all that seems to be happening is that it is rescheduling this one request over and over for the same user. No user has reported a problem with other emails.
Is there any way to lookup user id=6 so I can see who is being affected ?
I don’t know if it is related but have just looked at admin “error logs” and have found the following new entry
Message (416 copies reported)
Job exception: 451 Requested action aborted: local error in processing
### Backtrace
/usr/local/lib/ruby/2.5.0/net/smtp.rb:969:in `check_response' /usr/local/lib/ruby/2.5.0/net/smtp.rb:937:in `getok' /usr/local/lib/ruby/2.5.0/net/smtp.rb:865:in `rcptto' /usr/local/lib/ruby/2.5.0/net/smtp.rb:846:in `block in rcptto_list' /usr/local/lib/ruby/2.5.0/net/smtp.rb:844:in `each' /usr/local/lib/ruby/2.5.0/net/smtp.rb:844:in `rcptto_list' /usr/local/lib/ruby/2.5.0/net/smtp.rb:659:in `send_message' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/network/delivery_methods/smtp_connection.rb:54:in `deliver!' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/network/delivery_methods/smtp.rb:101:in `block in deliver!' /usr/local/lib/ruby/2.5.0/net/smtp.rb:519:in `start' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/message.rb:2159:in `do_delivery' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/message.rb:260:in `block in deliver' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionmailer-5.2.0/lib/action_mailer/base.rb:560:in `block in deliver_mail' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-5.2.0/lib/active_support/notifications.rb:168:in `block in instrument' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-5.2.0/lib/active_support/notifications/instrumenter.rb:23:in `instrument' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-5.2.0/lib/active_support/notifications.rb:168:in `instrument' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionmailer-5.2.0/lib/action_mailer/base.rb:558:in `deliver_mail' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mail-2.7.1.rc1/lib/mail/message.rb:260:in `deliver' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionmailer-5.2.0/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionmailer-5.2.0/lib/action_mailer/rescuable.rb:17:in `handle_exceptions' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionmailer-5.2.0/lib/action_mailer/message_delivery.rb:113:in `deliver_now' /var/www/discourse/lib/email/sender.rb:197:in `send' /var/www/discourse/app/jobs/regular/user_email.rb:46:in `execute' /var/www/discourse/app/jobs/base.rb:132:in `block (2 levels) in perform' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rails_multisite-2.0.5/lib/rails_multisite/connection_management.rb:63:in `with_connection' /var/www/discourse/app/jobs/base.rb:127:in `block in perform' /var/www/discourse/app/jobs/base.rb:123:in `each' /var/www/discourse/app/jobs/base.rb:123:in `perform' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:187:in `execute_job' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:169:in `block (2 levels) in process' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:128:in `block in invoke' /var/www/discourse/lib/sidekiq/pausable.rb:81:in `call' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:130:in `block in invoke' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:133:in `invoke' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:168:in `block in process' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:139:in `block (6 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/job_retry.rb:98:in `local' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:138:in `block (5 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq.rb:36:in `block in <module:Sidekiq>' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:134:in `block (4 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:199:in `stats' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:129:in `block (3 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/job_logger.rb:8:in `call' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:128:in `block (2 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/job_retry.rb:73:in `global' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:127:in `block in dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/logging.rb:48:in `with_context' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/logging.rb:42:in `with_job_hash_context' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:126:in `dispatch' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:167:in `process' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:85:in `process_one' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:73:in `run' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/util.rb:16:in `watchdog' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.1.3/lib/sidekiq/util.rb:25:in `block in safe_thread'
### Env
hostname xxx-app
process_id 23846
application_version 94622b451a19f0f5152280f146354ab663d06eb8
current_db default
current_hostname forum.xxx.com
job Jobs::UserEmail
problem_db default
opts type digest
--- --- --- ---
--- ---
user_id 6
current_site_id default
You can turn a user ID into a username with something like User.find(6).username in the rails console, but that’s unlikely to help you much. You’ll need to examine the mail server logs to determine why it’s giving a transient error.
You can turn a user ID into a username with something like User.find(6).username in the rails console
No idea what “rails console” is tried typing “rails console” at command prompts on server and I just get
The program ‘rails’ is currently not installed. You can install it by typing:
sudo apt install ruby-railties
examine the mail server logs
No idea where these can be. The server is an off-the-shelf DO droplet with Discourse pre-installed
Remember this has been working perfectly since months and has been sending out emails without a known problem up to the latest update v2.1.0.beta4 +16 It also worked just fine through the previous update (v2.1.0.beta3 +20)
That is why I posted this as a bug in v2.1.0.beta4 +16 (someone has moved it and changed the title to something meaningless too me) Nothing has come up about any ‘smtpserverbusy’ so why has that been added?
The total email jobs continues to grow (now at 54 retries) and they are all the same.
It’s not the droplet, because DO doesn’t really like it when people do that.
Well during the DO setup one of the first things requested was
“Enter the email address to use for the Discourse admin account (ex. user@example.org)Enter the email address to use for the Discourse admin account (ex. user@example.com)”
I added the email address of another domain I have hosted elsewhere with working email the domain is similar to the DO hosted domain but with different TLD
then the request was for Enter the SMTP server to use to send email (ex: smtp.example.org):
I use this smtp on another nginx server on DO for admin and it works
then the username, port and password were requested and entered.
As I indicated at the start of this topic everything has been working bug free from the original installed version (DO) through the previous version and has only started producing this error since the v2.1.0.beta4 +16 upgrade
New users seem to register ok, messages seem to go out ok but I cannot test for user=6 because I cannot identify which user that is.
Many thanks, Andrew, that was useful. It not only let me identify the user (6) but also gave me the date of last_email_at as: Wed, 20 Jun 2018 19:19:11 UTC +00:00,
That is a long time before either update and well prior to last visit and last post (only a couple of days ago)
The user panel shows 0 bounces but I have just sent the user an email to see if the email address given is still alive (just in case)
I’m going to kill all the Sidekiq retries as it seems pointless letting them continue to grow.