The existing capistrano callback order had the strange result of updating the crontab THEN clearing the crontab later in the deploy, always resulting in a empty crontab.
This branch uses before and after callbacks on the finalize_update method to ensure correct ordering.
update cap callback order so that crontab is cleared BEFORE updating …
…it instead of after
finalize_update is called inside the block of update_code
previous callback order would always clear the crontab
clear crontab before finalize_update but after update_code as the whe…
…never gem may not be available until the bundle is installed
deploy:update_code should happen at the very beginning of a deploy right after the new code is uploaded. Perhaps you have something executing that callback late in your deploy?
The idea here is disable cron jobs for the duration of the deploy and then reenable them with the new jobs at the very end.
It's entirely possible that something in my deploy changed that messed it up, as I'm sure it "used" to work. However after looking into the issue, I can't understand why it used to work.
finalize_update happens completely inside the update_code block so the order of callbacks is
The current whenever master code is
before "deploy:finalize_update", "whenever:update_crontab"
after "deploy:update_code", "whenever:clear_crontab"
How can that work?
whenever update must use the latest_release path to ensure it is usin…
…g the latest schedule
Why was this closed? Using default capistrano deploy recipe for the most recent release of capistrano (v2.12.0) the current behavior of whenever definitely appears broken.
Following the trail backwards, here's the significant changes. fba25d3 and 7ae1009.
I'm not actively using Whenever these days so if anyone can test this patch or recommend another, I'd be happy to merge.
/cc @sparrovv @leehambley
I have been using my branch in production over 4 different servers for the last 3 weeks without problem. (I had closed it as I figured I must be crazy if I was the only person with the problem)
Same problem here, although in my case the whenever:update_crontab task was never executed. I fixed it adding this line to my deploy.rb:
after 'whenever:clear_crontab', 'whenever:update_crontab'
Probably not the most elegant way to do it, but I like the idea of having one of the tasks depend on the other one.
I tested this locally and it both worked and solved a problem I was having with current_path vs. latest_release. +1 to merge.
Looking at this diagram (https://raw.github.com/mpasternacki/capistrano-documentation-support-files/master/default-execution-path/Capistrano%20Execution%20Path.jpg), I'm not positive this is the best approach.
What we want is for whenever:clear_crontab to run at the very beginning of a deploy, after the new code is uploaded. Then, at the very end, we want whenever:update_crontab to run.
Won't this change clear and then update all at the very end?
I'm getting intermittent crashes in whenever now when it tries to clear the crontab. Here's the output:
* executing `whenever:clear_crontab'
* executing "cd /var/web/turbovote/releases/20120824210617 && bundle exec whenever --clear-crontab turbovote"
servers: ["webapp1-staging.turbovote.org", "worker1-staging.turbovote.org"]
[webapp1-staging.turbovote.org] executing command
[worker1-staging.turbovote.org] executing command
** [out :: webapp1-staging.turbovote.org] [write] crontab file
** [out :: webapp1-staging.turbovote.org]
** [out :: worker1-staging.turbovote.org] /tmp/whenever_tmp_cron.25791.1954: No such file or directory
** [out :: worker1-staging.turbovote.org] [fail] Couldn't write crontab; try running `whenever' with no options to ensure your schedule file is valid.
I'm not sure if it's related to this change or not, though. I'm going to try moving the clear_crontab task to a point earlier in the deploy and see if that helps.
@cap10morgan Looks like the tmp file was never written or went away for some reason. I've never seen that. https://github.com/javan/whenever/blob/master/lib/whenever/command_line.rb#L69-72
Actually, does anyone see an issue with removing the whenever:clear_crontab task from the default recipe? whenever:update_crontab replaces any existing cron jobs so it does the same work. Clearing the crontab at the beginning serves to disable cron jobs during a deploy, but given how short a deploy can be it probably isn't added much benefit.
Removing whenever:clear_crontab is fine with me. I can't imagine the scenario where I want cron jobs not to run during deploy; we don't turn off the web server during a deploy.
I had a good reason when I added it; just can't remember now. 😐 I'll remove.
Done. 42fc19f If anyone has a moment to test, please do.