Capistrano callback order #233

Closed
wants to merge 3 commits into
from

4 participants

@s01ipsist

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.

s01ipsist added some commits Jul 15, 2012
@s01ipsist s01ipsist 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
https://github.com/mpasternacki/capistrano-documentation-support-files/raw/master/default-execution-path/Capistrano%20Execution%20Path.jpg
previous callback order would always clear the crontab
0446b02
@s01ipsist s01ipsist clear crontab before finalize_update but after update_code as the whe…
…never gem may not be available until the bundle is installed
8a93753
@javan
Owner

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.

@s01ipsist

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.
https://github.com/mpasternacki/capistrano-documentation-support-files/raw/master/default-execution-path/Capistrano%20Execution%20Path.jpg

finalize_update happens completely inside the update_code block so the order of callbacks is

before:update_code
before:finalize_update
after:finalize_update
after:update_code

The current whenever master code is
before "deploy:finalize_update", "whenever:update_crontab"
after "deploy:update_code", "whenever:clear_crontab"

How can that work?

@s01ipsist s01ipsist closed this Jul 17, 2012
@twalpole

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.

@javan javan reopened this Aug 7, 2012
@javan
Owner

Hey guys,

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

@s01ipsist

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)

@ghost

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.

@cap10morgan

I tested this locally and it both worked and solved a problem I was having with current_path vs. latest_release. +1 to merge.

@javan
Owner

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?

@cap10morgan

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.

@javan
Owner

@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

@javan
Owner

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.

@s01ipsist

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.

@javan
Owner

I had a good reason when I added it; just can't remember now. 😐 I'll remove.

@javan
Owner

Done. 42fc19f If anyone has a moment to test, please do.

@javan javan closed this Aug 26, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment