How to run sidekiq in production server?

Question

I have a server with apache + passenger.

How will I run sidekiq in production? Any configuration needed to run the

bundle exec sidekiq 

Thanks

Answer 1

bundle exec sidekiq -d -L log/sidekiq.log -C config/sidekiq.yml -e production

-d, Daemonize process

-L, path to writable logfile

-C, path to YAML config file

-e, Application environment

Answer 2

A better solution than using the daemonization -d flag is to leverage the process supervisor provided by your OS. This is also the recommendation given by the sidekiq gem's wiki:

I strongly recommend people not to use the -d flag but instead use a process supervisor like systemd or upstart to manage Sidekiq (or any other server daemon). This ensures Sidekiq will immediately restart if it crashes for some reason.

The wiki provides a example config files for both upstart and systemd found in the "examples" directory of the repo.

NOTE On my CentOS 7 server I use rvm (Ruby Version Manger). I had to perform an extra step to ensure that my systemd script (/etc/systemd/system/sidekiq.service) could reliably start and stop sidekiq, even in the case where my ruby and/or gemset paths change in the future. The most important directive is "ExecStart", which looks like the following in my script:

ExecStart=/usr/local/rvm/wrappers/surveil/bundler exec sidekiq -e production -L log/sidekiq.log -C config/sidekiq.yml 

The part of the path "/usr/local/rvm/wrappers/surveil", is actually a symlink, which I recreate with the assistance of 'rvm alias' during deployment to ensure that it always points to the app's ruby version and gemset, both of which could feasibly change from one deployment to another. This is achieved by creating a rake task that runs during deployment and does the equivalent of the following:

rvm alias delete surveil rvm alias create surveil ruby-#{new_ruby_version}@#{new_gemset_name} 

By setting up this alias/symlink during deployment, I can safely leave the systemd script untouched and it will keep working fine. This is because the path "/usr/local/rvm/wrappers/surveil/bundler" always points to the correct version of bundler and thus beneifts from the bundler magic that causes its targets to run in the app's configured ruby/gem environment.