What possible reasons can Sidekiq prevent from processing jobs in the queue? The queue is full. The log file sidekiq.log indicates no activity at all. Thus the queue is full but the log is empty, and Sidekiq does not seem to process items. There seem to no worker processing jobs. Restarting Redis or flush it with FLUSHALL or FLUSHDB has no effect. Sidekiq has been started with
bundle exec sidekiq -L log/sidekiq.log
and produces the following log file:
2013-05-30..Booting Sidekiq 2.12.0 using redis://localhost:6379/0 with options {}
2013-05-30..Running in ruby 1.9.3p374 (2013-01-15 revision 38858) [i686-linux]
2013-05-30..See LICENSE and the LGPL-3.0 for licensing details.
2013-05-30..Starting processing, hit Ctrl-C to stop
How can you find out what went wrong? Are there any hidden log files?
The reason was in our case: Sidekiq may look for the wrong queue. By default Sidekiq uses a queue named "default". We used two different queue names, and defined them in config/sidekiq.yml
# configuration file for Sidekiq
:queues:
- queue_name_1
- queue_name_2
The problem is that this config file is not automatically loaded by default in your development environment (unlike database.yml or thinking_sphinx.yml for instance) by a simple bundle exec sidekiq command. Thus we wrote our jobs in two certain queues, and Sidekiq was waiting for jobs in a third queue (the default one). You have to pass the path to the config file as a parameter through the -Cor --config option:
bundle exec sidekiq -C ./config/sidekiq.yml
or you can pass the queue names directly (no spaces allowed here after the comma):
bundle exec sidekiq -q queue_name_1,queue_name_2
To find the problem out it is helpful to pass the option -v or --verbose at the command line, too, or to use :verbose: true in the sidekiq.yml file. Everything which is defined in a config file is of course useless if the config file is not loaded.. Therefore make sure you are using the right config file first.
If you have a config/sidekiq.yml check that all the queues are defined there, check this sample file: https://github.com/mperham/sidekiq/blob/master/examples/config.yml
If you are passing queue names in the command line or Procfile, something similar to
bin/sidekiq -q queue1 -q queue2
bundle exec sidekiq -q queue1 -q queue2
check that all your queues are defined there.
In case you are not sure about the names of your queues, you can figure it out with the following script:
require "sidekiq/api"
stats = Sidekiq::Stats.new
stats.queues
# {"production_mailers"=>25, "production_default"=>1}
Then, you can do things with the queues:
queue = Sidekiq::Queue.new("production_mailers")
queue.count
queue.clear
It took me hours to find out that I had set config.active_job.queue_name_prefix = "xxxxx_#{Rails.env}". The queue names in the settings look the same, but sidekiq looks for the queue with prefix.
Wrong setting
app/jobs/my_job.rb
class MyJob < ApplicationJob
queue_as :default
end
config/sidekiq.yml
:queues:
- default
Correct setting
app/jobs/my_job.rb
class MyJob < ApplicationJob
queue_as :default
end
config/sidekiq.yml
:queues:
- xxxxx_development_default
- xxxxx_production_default
My problem was I had a configure_server but not configure_client in my initialiser, you must have both:
Sidekiq.configure_server do |config|
config.redis = { url: ENV.fetch('SIDEKIQ_REDIS_URL', 'redis://127.0.0.1:6379/1') }
end
Sidekiq.configure_client do |config|
config.redis = { url: ENV.fetch('SIDEKIQ_REDIS_URL', 'redis://127.0.0.1:6379/1') }
end
In my case, sidekiq was fine in development, but stuck in staging. It was human error on the capistrano's deploy configuration. I set the path for sidekiq.yml incorrectly in the Capfile (shared instead of current).
It failed silently:
# Capfile
# WRONG:
set :sidekiq_config, -> { File.join(shared_path, 'config', 'sidekiq.yml') }
^^^^^^^^^^^
# RIGHT:
set :sidekiq_config, -> { File.join(current_path, 'config', 'sidekiq.yml') }
flushing redis worked for me.
WARNING: THIS WILL REMOVE ALL DATA IN YOUR REDIS DATABASE.
redis-cli flushall
I was banging my head against a brick wall on this for a while, my issue was that sidekiq required a newer version of redis-server. I ran "bundle exec sidekiq" and that revealed the error. Once I updated to a newer version of redis-server it was fine.
I just had this issue. Turns out I had made a syntax error in my sidekiq.yml
Spent at least two hours on this as well because queues and configuration and web UI were all fine ... the jobs were just not processed.
My issue was that the sidekiq-server was not running in my docker-compose setup even though it should have been started in the command-section here:
sidekiq:
depends_on:
- 'proddb'
- 'redis'
build: rails-app
--> command: bundle exec sidekiq --environment ${RAILS_ENV} -C config/sidekiq.yml
volumes:
- './rails-app:/project'
- '/project/tmp' # don't mount tmp directory
environment:
- REDIS_URL_SIDEKIQ=${REDIS_URL_SIDEKIQ}
networks:
- backend
My problem was I did not config my initializers/sidekiq.rb properly but even with the correct config, sidekiq was still not running enqueued jobs. I had to run spring stop on top of that and restarted everything and it solved my issue.
I encountered a similar problem wherein the logs would show entries such as INFO Rails : queueing TestWorker (TestWorker). However, the jobs would never get processed, and none of the answers in this question solved the issue.
The tl;dr to my solution is that Sidekiq's Testing Client was getting unexpectedly triggered.
I eventually deduced that there is some "magic" going on underneath the surface that makes it difficult to discretely determine where/when/how the above testing trigger was getting configured, based on the following anecdote...
Running bundle exec sidekiq -C config/sidekiq.yml -e development had the result that Sidekiq::Testing.fake? == true
However, running bundle exec sidekiq -C config/sidekiq.yml -e development_2 had the result that Sidekiq::Testing.fake? == false
^ The only difference between these 2 commands is that I renamed the development environment in sidekiq.yml to development_2, i.e. the same/equivalent environment was running with both commands (at least, presumably it would be the same environment if it wasn't for this inane "magic" under the hood).
I updated sidekiq.rb to explicitly toggle Sidekiq::Testing via the following:
sidekiq_testing_fake = false # set this using env var, etc.
if sidekiq_testing_fake
Sidekiq::Testing.fake!
elsif Sidekiq.constants.include?(:Testing)
Sidekiq::Testing.disable!
end
My issue was that I had both a redis-server running and Redis.app's redis-server running, I killed the redis-server (and kept the Redis.app one)
Related
I created a Django application which runs inside a Docker container. I needed to create a thread inside the Django application so I used Celery and Redis as the Celery Database.
If I install redis in the docker image (Ubuntu 14.04):
RUN apt-get update && apt-get -y install redis-server
RUN pip install redis
The Redis server is not launched: the Django application throws an exception because the connection is refused on the port 6379. If I manually start Redis, it works.
If I start the Redis server with the following command, it hangs :
RUN redis-server
If I try to tweak the previous line, it does not work either :
RUN nohup redis-server &
So my question is: is there a way to start Redis in background and to make it restart when the Docker container is restarted ?
The Docker "last command" is already used with:
CMD uwsgi --http 0.0.0.0:8000 --module mymodule.wsgi
RUN commands are adding new image layers only. They are not executed during runtime. Only during build time of the image.
Use CMD instead. You can combine multiple commands by externalizing them into a shell script which is invoked by CMD:
CMD start.sh
In the start.sh script you write the following:
#!/bin/bash
nohup redis-server &
uwsgi --http 0.0.0.0:8000 --module mymodule.wsgi
When you run a Docker container, there is always a single top level process. When you fire up your laptop, that top level process is an "init" script, systemd or the like. A docker image has an ENTRYPOINT directive. This is the top level process that runs in your docker container, with anything else you want to run being a child of that. In order to run Django, a Celery Worker, and Redis all inside a single Docker container, you would have to run a process that starts all three of them as child processes. As explained by Milan, you could set up a Supervisor configuration to do it, and launch supervisor as your parent process.
Another option is to actually boot the init system. This will get you very close to what you want since it will basically run things as though you had a full scale virtual machine. However, you lose many of the benefits of containerization by doing that :)
The simplest way altogether is to run several containers using Docker-compose. A container for Django, one for your Celery worker, and another for Redis (and one for your data store as well?) is pretty easy to set up that way. For example...
# docker-compose.yml
web:
image: myapp
command: uwsgi --http 0.0.0.0:8000 --module mymodule.wsgi
links:
- redis
- mysql
celeryd:
image: myapp
command: celery worker -A myapp.celery
links:
- redis
- mysql
redis:
image: redis
mysql:
image: mysql
This would give you four containers for your four top level processes. redis and mysql would be exposed with the dns name "redis" and "mysql" inside your app containers, so instead of pointing at "localhost" you'd point at "redis".
There is a lot of good info on the Docker-compose docs
use supervisord which would control both processes. The conf file might look like this:
...
[program:redis]
command= /usr/bin/redis-server /srv/redis/redis.conf
stdout_logfile=/var/log/supervisor/redis-server.log
stderr_logfile=/var/log/supervisor/redis-server_err.log
autorestart=true
[program:nginx]
command=/usr/sbin/nginx
stdout_events_enabled=true
stderr_events_enabled=true
chef-solo hangs at the end when installing redis as if chef is waiting for some event to occur. Here is output when I had to kill it with ctrl+c.
[2013-05-14T15:55:27+00:00] ERROR: Running exception handlers
[2013-05-14T15:55:27+00:00] ERROR: Exception handlers complete
Chef Client failed. 8 resources updated
[2013-05-14T15:55:27+00:00] FATAL: Stacktrace dumped to /home/ubuntu/cache/chef-stacktrace.out
[2013-05-14T15:55:27+00:00] FATAL: Chef::Exceptions::MultipleFailures: Multiple failures occurred:
* SystemExit occurred in chef run: service[redis] (redis::default line 107) had an error: SystemExit: exit
* Chef::Exceptions::Exec occurred in delayed notification: service[redis] (redis::default line 83) had an error: Chef::Exceptions::Exec: /sbin/start redis returned 1, expected 0
I am new to chef and unable to figure out why this is happening. Has anyone noticed this behaviour before?
Here is my recipe file
package "build-essential" do
action :install
end
user node[:redis][:user] do
action :create
system true
shell "/bin/false"
end
directory node[:redis][:dir] do
owner node[:redis][:user]
group node[:redis][:user]
mode "0755"
action :create
end
directory node[:redis][:data_dir] do
owner node[:redis][:user]
group node[:redis][:user]
mode "0755"
action :create
end
directory node[:redis][:log_dir] do
owner node[:redis][:user]
group node[:redis][:user]
mode "0755"
action :create
end
remote_file "#{Chef::Config[:file_cache_path]}/redis-2.6.10.tar.gz" do
source "http://redis.googlecode.com/files/redis-2.6.10.tar.gz"
action :create_if_missing
end
# Adding 'make test' causes the install to freeze for some reason.
bash "compile_redis_source" do
cwd Chef::Config[:file_cache_path]
code <<-EOH
tar zxf redis-2.6.10.tar.gz
cd redis-2.6.10
make && sudo make install
# to give permissions to the executables that it copied to.
chown -R redis:redis /usr/local/bin
EOH
creates "/usr/local/bin/redis-server"
end
service "redis" do
provider Chef::Provider::Service::Upstart
subscribes :restart, resources(:bash => "compile_redis_source")
supports :restart => true, :start => true, :stop => true
end
template "redis.conf" do
path "#{node[:redis][:dir]}/redis.conf"
source "redis.conf.erb"
owner node[:redis][:user]
group node[:redis][:user]
mode "0644"
notifies :restart, resources(:service => "redis")
end
template "redis.upstart.conf" do
path "/etc/init/redis.conf"
source "redis.upstart.conf.erb"
owner node[:redis][:user]
group node[:redis][:user]
mode "0644"
notifies :restart, resources(:service => "redis")
end
service "redis" do
action [:enable, :start]
end
There are 2 service "redis" resource statements, is that a problem? or how does chef workout in this case, does it merge into a single resource when running?
I am using upstart and here is the redis.upstart.conf.erb file. Not sure if anything is wrong with this. Does the order of the statement matter in this file?
#!upstart
description "Redis Server"
emits redis-server
# run when the local FS becomes available
start on local-filesystems
stop on shutdown
setuid redis
setgid redis
expect fork
# Respawn unless redis dies 10 times in 5 seconds
#respawn
#respawn limit 10 5
# start a default instance
instance $NAME
env NAME=redis
#instance $NAME
# run redis as the correct user
#setuid redis
#setgid redis
# run redis with the correct config file for this instance
exec /usr/local/bin/redis-server /etc/redis/redis.conf
respawn
#respawn limit 10 5
I think Dmytro was on the right path, but not exactly.
I see that you are using Upstart as the service provider in Chef. Please check your Upstart config for redis-server for any expect statement. If you have an expect fork or expect daemon statement in there, it means that when starting redis-server, Upstart will be waiting for the Redis service to fork once or twice respectively. If you have daemonize no in the redis.conf, Redis process will never fork, and therefore Upstart just hangs at the execution of the init script.
Your redis is not failing to start, it simply runs in the foreground.
I had similar problem with one of the Redis cookbooks I was using. In the redis.conf.erb file it had configuration option
daemonize no
Some other cookbooks have this option configurable by attribute. So, your fix would depend on the cookbook you are using. Either edit your redis.conf.erb file or find how that attribute is configured and set it to yes.
I need to monitor my delayed_job worker with god. It starts perfectly, but when i want to stop it using "sudo god stop dj" it says
Sending 'stop' command
The following watches were affected:
dj-0
But worker is still on(it processes tasks etc.)
I looked through sites providing their god configs for delayed_job and stop command wasn't specified there. Do I need to specify stop task for god config or smth?
I start delayed_job with w.start = "cd #{rails_root} && QUEUE=work_server1 bundle exec rake -f #{rails_root}/Rakefile RAILS_ENV=#{environment} --trace jobs:work"
I've solved this problem. The reason was that using "bundle exec" two processes were spawned and god was monitoring the wrong one. So I've just upgraded rake to not use "bundle exec" and it works.
I am using whenever to fire a rake task every 5 minutes for my app.
schedule.rb:
every 5.minutes do
rake "audit",
:environment => 'development'
end
"whenever" in console:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /bin/bash -l -c 'cd /Users/john/Sites/rambler && RAILS_ENV=development bundle exec rake audit --silent'
"rake audit" in console works properly.
So all looks good .... except it doesn't work. Nothing happens every five minutes.
Is this because I am trying to run it in development / local?
Thanks!
You need to update your cron file every time you change it.
After you have addded your cron job do this:
whenever --update-crontab 'project_name'
Also I only found whenever working fine in production mode only.
UPDATE:
I have found that we can use whenever in development mode also. Just add
set :environment, "development"
set :output, {:error => "log/error.log", :standard => "log/cron.log"}
to your scehdule.rb file. ( The log one is optional but still you can use that for testing purpose)
Finally I have solved how to run the gem Whenever. It's working good on production, but not in development mode (I think that to working good in dev mode you must do some tricks).
see this answer for working in dev mode: Cron not working in Whenever gem
Then, these are the processes to do:
install the gem
write your scheduler.rb file
push to the remote server
login to the remote server (for example with ssh)
see if whenever is good uploaded by running in terminal: whenever
update whenever crontab by running: whenever --update-crontab
restart the server crontab (for example in ubuntu): sudo service cron restart
check if crontab are good implemented on the server: crontab -l
That is!
I'm struggling to get delayed_job working under rails 3.0.9 (ruby 1.9.2). The only way I have succeeded to run is to tape manualy the command rake jobs:work.
But I want that to be automatically started when the rails application is starting.
I have installed monit under ubuntu and I configured it to launch a file located in my app. This fails looks like:
check process delayed_job with pidfile /home/me/myapp/tmp/pids/delayed_job.pid
start program = "/home/me/myapp/script/delayed_job start"
stop program = "/home/me/myapp/script/delayed_job stop"
And I added the environment setting in the delayed_job script file:
#!/usr/bin/env ruby
ENV['RAILS_ENV'] = "development"
require File.expand_path(File.join(File.dirname(__FILE__), '..', 'config', 'environment'))
require 'delayed/command'
Delayed::Command.new(ARGV).daemonize
When I run the command "sudo monit start delayed_job" I get the following error:
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- bundler/setup (LoadError)
So I guess it is because sudo is using a wrong version of ruby environment
I tried then the solution of:
rvm monit delayed_job
by adding rvm -S in the start program / stop program lines.
But it still failing with the error : rvm command not found
my rvm dir is located in my home dir /home/me/.rvm
I tried to find workarounds in (sudo changes PATH - why?) to change the PATH environment variable by adding
/usr/bin/env PATH=/home/me/.rvm/bin:$PATH
The command "sudo monit start delayed_job" succeeded! and the worker started.
But the issue is: When I launch sudo /etc/init.d/monit start and when I look to the syslog I still get 'delayed_job' failed to start
So I don't know how to investigate more, how to get more verbose errors for monit.
I have finally succeeded to solve this issue.
I modified the monit file like this:
check process delayed_job with pidfile /home/me/myapp/tmp/pids/delayed_job.pid
start program = "/bin/su - me -c 'cd /home/me/myapp/; script/delayed_job start'"
stop program = "/bin/su - me -c 'cd /home/me/myapp/; script/delayed_job stop'"
I have also downgraded the daemons gem because it seems that there are problems with the latest version. So I'm using now daemons v 1.0.10
I also modified the rights of the log file /home/me/myapp/log/delayed_job.log, because it seems that is was created before my root and my user had no access to it (I had problems to test the command "script/delayed_job start" with "me" user)
This i s the only line that worked for me that read the ENV properly
start program = "/usr/local/rvm/bin/rvm-shell -c 'cd /var/www/[APP]/current/; RAILS_ENV=production bundle exec bin/delayed_job start'"
Hope it helps!