Understanding your type of cronjob

Some cronjobs must only run on a single server. E.g. when you run nightly batch operations on the database, it should probably run on a single server. Running it on multiple servers would likely result in deadlocks or corrupt data.

Do you need DevOps-experts?

Your development team has a full backlog? No time for infrastructure architecture? Our DevOps team is ready to support you!

• We build reliable cloud solutions with Infrastructure as code
• We are experts in security, Linux and databases
• We support your dev team to perform

Read more Show archive.org snapshot

Some cronjobs must always run on all servers. E.g. starting a sidekiq process on reboot.

Configuring whenever

If not configured otherwise, cronjobs defined in whenever's Show archive.org snapshot schedule.rb will only be written to the crontab of the server with the db role in deploy.rb.

If there are cronjobs that should run on all servers, you will have to change the default setting of whenever_roles.

What works well for us is using the roles cron and primary_cron:

• cron for all jobs that should run on all servers
• primary_cron for jobs that should run only on one server

From the docs Show archive.org snapshot :

If a server's role is listed in the whenever_roles, then it will have all jobs added to its crontab that either list that role in their :roles arg or that don't have a :roles arg.

Example

production.rb

server "server1.example.com", :app, :web, :db, :cron, :primary_cron, primary: true
server "server2.example.com", :app, :web, :cron

deploy.rb

set :whenever_roles, %i[cron primary_cron]

schedule.rb

every :reboot do
  rake 'sidekiq:start', output: { standard: nil }
end

every 10.minutes, at: 2, roles: [:primary_cron] do
  bundle_exec 'bin/jobs/my_single_server_job'
end

Note: If sidekiq does not run on all servers, you could use a dedicated role sidekiq for the restart entry.