Rufus Scheduler Not Running in Production

rufus scheduler not running in production

Most likely, this problem is caused by the Rufus scheduler background thread being terminated after Phusion Passenger spawns a child process as part of the smart spawning method.

Read Spawning methods explained.
The specific issue you're suffering from is probably Smart spawning caveat #2: the need to revive threads.

You need to revive the Rufus scheduler thread using the mechanism in the documentation. I'm not exactly sure which API call you need to make, so maybe you can ask the Rufus scheduler authors.

Alternatively, you can use the 'direct' spawning method. It's less efficient but it avoids compatibility issues like this.

Rufus Scheduler not running

If your script exits right away please try to add

scheduler.join

at the end. Please note that it's different when running the script stand alone and via rails. See the README for detailled information.

Rufus cron scheduling not working on a jetty server

You're saying "it's not scheduling". I guess you've waited until the specified 1815 but nothing happened.

According to your previous question (Why is Rufus scheduling the job twice?) rufus-scheduler is actually scheduling, so what's happening?

Rufus-scheduler 3.3.3 (the one you seem to be using) defaults to using Rails' timezone. This timezone is set in config/application.rb and defaults to UTC.

Could it be that you waited until 1815 local time (not UTC time) and nothing happened?

Try with a schedule like "* * * * *" (every minute) or "*/5 * * * *" (0, 5, 10, 15, ... minute).

Rufus-scheduler only running once on production

You probably shouldn't run rufus-scheduler in the rails server itself, especially not with a multi-process framework like passenger. Instead, you should run it in a daemon process.

My theory on what's happening:

Passenger starts up a ruby server process and uses it to fork off other servers to handle requests. But since rufus-scheduler runs its jobs in a separate thread from the main thread, the rufus thread is only alive in the original ruby process (ruby's fork only duplicates the thread that does the forking). This might seem like a good thing because it prevents multiple schedulers from running, but... Passenger may kill ruby processes under certain conditions - and if it kills the original, the scheduler thread is gone.

How to check if rufus-scheduler is already running for my Rails Application

If you bring in a cron task to watch rufus-scheduler, why don't you simply drop rufus-scheduler and use Whenever for all the scheduling? You'll thus have a 100% crond solution.

Another alternative, use Foreman to manage a) your Rails application b) a separate process hosting your rufus-scheduler schedules (it could be a "schedule only" version of your Rails application) (here is a nice example in a blog post). There is also God.

If you look at Clockwork, a gem that was inspired by rufus-scheduler, they detail such one application / multiple processes scenarii.

Then you could look at the various tools out there to watch your logs and alert you in case of error.

Update:

Maybe this gist could help: https://gist.github.com/jmettraux/5f716c8568f6ab7bb016a4bc11528bc2

Rufus scheduler not logging in production

OK, found the problem, thanks to this article: http://earthcode.com/blog/2009/05/rails_script_runner_logging_cron.html

Turns out the logger will not auto-flush in production. So, I just added

logger.flush

to the end of the process and BANG everything worked.

Running a cron on start-up using Rufus Scheduler 2.x

a plain way of doing it would be:

job =
  proc do
    puts "hello"
  end

job.call
  # run it right now

scheduler.cron('00 00 * * *', &job)

But maybe this one is more readable:

job =
  scheduler.cron '00 00 * * *' do
    puts 'hello'
  end

job.block.call
  # run it right now

scheduler.join

Thanks for posting a new question, it made everything clear. The question at Rufus Scheduler :first_in option unknown with cron is a bit different.

I know this is about rufus-scheduler 2.0.24, but I'd like to point to a new feature in 3.3.x: https://github.com/jmettraux/rufus-scheduler/issues/214 where you can do job.trigger_off_schedule and it invokes the job right now if overlap, mutex and other job options allow it.

Back to 2.0.24, the shortcut shown above has no refinement, it will run the block right now. The block might already have an instance running now, imagine you have the schedule set for "midnight every night" and you happen to restart at midnight. Hence, I think the first solution above, is best, because it triggers then schedules.