I implemented the delayed job & it is processing fine but it is generating the mails in development.log not in production.log.
Also no mail is actually sent, it's just generating in development log. After processing I have no job in delayed job table also.
I also used RAILS_ENV=production rake jobs:work but still the mail is in development log and is not actually sent; I am using mail server on Ubuntu to send mails.
I have noticed that rake jobs:work by default uses the development log don't know is it same for the production server too?
If somebody know the problem then please answer ASAP because my application has been stuck due to this on the production server and lots of mails are just going in development log and not actually going to the end user.
This may be obvious, but in your config/production.rb, have you set
config.action_mailer.delivery_method = :smtp
It's possible you set the delivery method in config/development.rb, but forgot to do the same in the production environment. Please let me know so I can help further!
Related
I am running rails 5.1.0
In config/environments/test, I have config.action_mailer.perform_deliveries = false.
I am running a rails server with -e test to perform end to end to tests.
When I switch the server back to the dev environment, it loads a new browser tab rendering every email that wasn't sent during my tests. If I run my tests 5-6 times, this results in 50 browser tabs opening at once when I switch back to development.
For perform_deliveries Rails docs say:
If this value is false, deliveries array will not be populated even if
delivery_method is :test.
I am also running sidekiq and redis, so I wasn't sure if I have to somehow set the environment on those.
Is there a way for me to completely prevent emails from being queued into the system in my testing envrionment?
You can clear the sidekiq queue after you have run the server in the test environment. Or use other queue name in the test environment.
But the main thing is you should never run server in this mode.
For test you should use unit-tests or better rspec.
I'm have a server where I deploy using capistrano and I use delayed_jobs to do some mailing but at my server for some reason the jobs do not execute. The delayed_job process is running (running bin/delayed_job status answers me correctly saying there's a process there by some pid), but I don't know if the process just isn't executing my jobs or even if my jobs aren't being enqueued. Locally it all works fine, but at production staging in the server it does not.
I'd like to know if there's a way I can at least check what jobs are there, since I can't do it by accessing the console
Another gem that works with delayed job is delayed-web which you can find here https://github.com/tatey/delayed-web
you add it to your gemfile
gem 'delayed-web'
then run
rails generate delayed:web:install
this will generate an initializer file delayed_web.rb under config/initializers with the following:
Rails.application.config.to_prepare do
Delayed::Web::Job.backend = 'active_record'
end
and in config/application.rb this will be added for you as well by the generator
# config/application.rb
config.assets.enabled = true
config.assets.precompile << 'delayed/web/application.css'
In routes.rb it may add a route as well but if you are using devise then maybe you want to restrict access to admin user(s) only as follows:
authenticated :user, -> user { user.admin? } do
mount Delayed::Web::Engine, at: '/jobs'
end
Ok so I'm checked my jobs through the database itself, I entered psql through postgres user and did some queries in the delayed_jobs table, you can also try doing RAILS_ENV=production bin/delayed_jobs run (for rails 4, rails 3 use "script/" instead of "bin/") which will show you what the workers are doing while they execute the job.
You can also, as Swards commented above, use a gem to have a web interface for delayed_jobs: https://github.com/ejschmitt/delayed_job_web
If you still wanna see what was my problem with the email sending I've opened another question because it got to far away from what this one was about: What port to use sending email with SMTP (mailgun) in rails app on production server (DigitalOcean)?
My Gitlab (version 5) is not sending any e-mails and I am lost trying to figure out what is happening. The logs give no useful information. I configured it to used sendmail.
I wrote a small script that sends e-mail through ActionMailer (I guess it is what gitlab uses to send e-mail, right?). And it sends the e-mail correctly.
But, on my Gitlab, I can guarantee that sendmail is not even being called.
Do I need to enable something to get e-mail notifications? How can I debug my issue?
Update
The problem is that I can not find any information anywhere. The thing just fails silently. Where can I find some kind of log? The logs in the log dir provide no useful information.
My question is, how can I make Gitlab be more verbose? How can I make it tell me what is going on?
Update 2
I just found a lot of mails scheduled on the Background jobs section. A lot of unprocessed Sidekiq::Extensions::DelayedMailer. What does it mean? Why were these jobs not processed?
Stumbled upon this issue today, here's my research:
Debugging SMTP connections in the GitLab GUI is not supported yet. However there is a pending feature request and a command line solution.
Set the desired SMTP settings /etc/gitlab/gitlab.rb and run gitlab-ctl reconfigure (see https://docs.gitlab.com/omnibus/settings/smtp.html).
Start the console running gitlab-rails console -e production.
Show the configured delivery method (should be :smtp) running the command ActionMailer::Base.delivery_method. Show all configured SMTP settings running ActionMailer::Base.smtp_settings.
To send a test mail run
Notify.test_email('youremail#example.com', 'Hello World', 'This is a test message').deliver_now
On the admin page in GitLab, the section »Background jobs« shows information about all jobs. Failing SMTP connections are listed there as well.
Please note, you may need to restart the GitLab instance in order to use the newly configured SMTP settings (on my instance the console was able to send mails, the GUI required a restart). Run gitlab-ctl restart to restart your instance.
First, I will tell what was my problem: The sidekiq is responsible for handling sending e-mails. For some reason my sidekiq was stuck, restarting it solved the problem.
Where I found information about problems I found on Gitlab:
The logs dir. It has a few informations.
On admin page, the section "Background jobs" gives information about the sidekiq.
The javascript console (if your browser supports it) also has useful information. Only if your problem is related to javascript.
And if you reach this point, you may modify Gitlab's code so you can "trace it" writing to a file:
File.open('/tmp/logfile','a') { |file| file.write("Hello World!\n") }
Maybe try enabling delivery errors in production mode and see what happens
config.action_mailer.raise_delivery_errors = true
I had the same problem and found that I needed to mod application.rb:
diff --git a/config/application.rb b/config/application.rb
index d85bcab..274976f 100644
--- a/config/application.rb
+++ b/config/application.rb
## -11,6 +11,8 ## end
module Gitlab
class Application < Rails::Application
+ config.action_mailer.sendmail_settings = { :arguments => "-i" }
+
# Settings in config/environments/* take precedence over those specified here.
# Application configuration should go into files in config/initializers
# -- all .rb files in that directory are automatically loaded.
Note: I'm running Debian 7 which uses exim for mail.
In the admin section under Background Jobs if you have lots of items in the Scheduled tab try restarting sidekiq:
cd /home/git/gitlab
exec rake sidekiq:start RAILS_ENV=production
I have my app in production mode in my linode account and I get in one page a 500 internal server error the message:
We're sorry, but something went wrong.
However in my development environment works fine this page.
How can I debug this error?
How can I see the error origin in my production mode?
I want that rails show errors in production mode.
How can I do it?
Thank you!
If you have access to ssh, log in to your server via ssh and go to your rails log directory, which is inside your rails directory.
Once you are there run the command tail production.log . If this doesn't give you enough information you can also do a tail -n100 production.log (gives you last hundred lines of the production log).
If you have deployed via heroku, then you can access the logs by running heroku logs in your local console. (more information here https://devcenter.heroku.com/articles/logging)
I also find it helpful to use the exception_notification gem https://github.com/rails/exception_notification when running in production, as it emails you a stacktrace when an error occurs. Plenty of others also use Hoptoad (http://hoptoadapp.com/) or Exceptional (http://www.exceptional.io/) however i prefer the simple exception_notification gem.
Also, in some rare occasions when i can't trace the error as a final measure i sometimes open up port 3000 temporarily on the remote server firewall and cd to the rails project and run rails server production with the log level set to debug in config/environments/production.rb so i can see the error in the console, and then close off the port when i have finished.
Hope that helps.
tail -n100 production.log
will only show the last 100 lines of the log file. Just in case you want to see the log running in real time.
use this
tail -1000f log/production.log
I set up hoptoad on my prod server and ran rake hoptoad:test. I get the notifier in my hoptoad interface so it seems to work great. But then I forgot to migrate my database after my last deploy so I got a "ActionView::TemplateError" in my production log. This caused a 500 so I feel like HopToad should have notified me about this. Have any hoptoad users out there had this issue?
As a side note, is it standard practice to have your deploy process automatically migrate your production database?
Thanks!
As a side note, is it standard
practice to have your deploy process
automatically migrate your production
database?
The choice belongs to you. It's a standard practice to use Capistrano for deploying Rails apps. With capistrano you can run
cap deploy # to deploy the app
cap deploy:migrate # to migrate the app
cap deploy:migrations # to deploy and migrate at the same time
You can decide whether to execute the commands separately or not.
About hoptoad, I'm sorry but I don't have a Rails app with hoptoad installed to test against.
Did you have any exception notification or logging plugins installed before hoptoad? If so, make sure you remove them. I had minor issues setting up hoptoad because of this interference.
Make sure your production server is set to the RAILS_ENV "production". Development doesn't trigger hoptoad.