-
Notifications
You must be signed in to change notification settings - Fork 954
Common problems
- If delayed_job appears to start but the process isn't running
- check that
log/delayed_job.log
is writeable or wherever you are writing logs - check that
tmp/pids/
exists and is writable, you should see a filetmp/pids/delayed_job.pid
when the process is running - try
bin/delayed_job run
and see if any errors are shown, this does not fork a new process - specify your rails environment, e.g.
RAILS_ENV=production bin/delayed_job
- try running as root to rule out permission problems
- check that
- Does your database include the
delayed_jobs
table? If not, go through installation instructions again. - Start your app with no workers and check if jobs are added in the database. If not, see "No jobs are added in the database"
- If jobs are present, then launch manually one worker :
rake jobs:work
. Jobs should be processed and disappear from the database.- If jobs are still here, do they show an error?
- If jobs are no longer in the database, see log/delayed_job
- If jobs have been removed from the database with no reported error, see "jobs are silently removed from the database"
- is your job's serialised error message too big to fit into delayed_jobs#last_error? This will crash the background task. You may mitigate by increasing the limit for that column.
Assuming the delayed_job table is here, try to inspect the logs (log/development.log). Do you use protection against mass assignment ? If yes, you should relax the rules for two fields :
ActiveRecord::Base.send(:attr_accessible, :priority) ActiveRecord::Base.send(:attr_accessible, :payload_object)
Just like you probably did for the sessions, cf. http://railsforum.com/viewtopic.php?id=32634
If the delayed_job worker cannot process the YAML code in the 'handler' field, it will permanently fail the job and, by default, remove the job from the job table. Make sure to set Delayed::Worker.destroy_failed_jobs = false so that the job stays in the table and retains the error.
One common cause of deserialization errors is that the YAML references a class not known to the worker. If this is the case, you can add
# file: config/initializers/custom.rb require 'my_custom_class'
which will force my_custom_class to be loaded when the worker starts.
According to the official Rails guides http://guides.rubyonrails.org/action_mailer_basics.html#adding-attachments, the mail gem will automatically guess the mime_type and set the encoding for emails with attachments. This does not work when the email is delivered asynchronously using delayed_job, and the email will be sent without the attachments.
To fix this, remember to add this line to your mailer: content_type "multipart/mixed"
Try:
RAILS_ENV=production script/delayed_job start
Or for Rails 4:
RAILS_ENV=production bin/delayed_job start
More info: https://github.com/collectiveidea/delayed_job/issues/7
DJ isn't intended to work with unsaved ActiveRecord models.
Possible solutions:
- Save the model before using it in a job
- If you need access to temporary data that isn't persisted with the model, create a job class that takes the attributes as its data. As part of the job's perform method, do whatever task you need to do and then save the model.