Inspecting the contents and comparing the pids specified in the files vs the ones that are running may give you clues to the problem.
Make a note of your pids pre-deploy; do the deploy then compare the pids previous; to the current pids; and to the pids in the directory. On Feb 7, 2013, at 6:45 AM, bsod99 <[email protected]> wrote: > Further update on this, in case it helps pinpoint the issue(s) - when an > error (as described above) arises after a deployment, if I remove the > releases/cached-copy/log/pids folders and run deploy:setup and deploy, my > sites work correctly. > > On Wednesday, 6 February 2013 21:49:09 UTC, bsod99 wrote: >> >> I'm on CentOS 6, standard LAMP setup. It's really puzzling. >> >> I wonder if I should just start afresh, as I've been messing about with the >> deployment script a fair bit. >> >> On Wednesday, 6 February 2013 17:46:37 UTC, dbray wrote: >>> >>> What web server are you using. I experienced something similar with >>> unicorn. Because of its forking the master process it had already resolved >>> the symlink to a specific directory. Everything would work fine until the >>> original dir the master was originally started from finally got cleaned up. >>> >>> I used to use passenger and it had similar issues until they incorporated a >>> patch to re-evaluate the symlink for each fork. >>> >>> On Feb 6, 2013, at 4:30 AM, bsod99 <[email protected]> wrote: >>> >>>> Thanks, switched to latest_release. All the targets exist in shared, and >>>> 'cap deploy:shared_symlinks' is executing successfully during the >>>> deployment. Checking the symlinks after shows they are correct. >>>> >>>> The cap task isn't raising any errors. The issue is that non-shared core >>>> classes in my application are sporadically not found after a deployment, >>>> even though these files are sitting in the current release in the correct >>>> place. Also, upon re-deploying, sometimes the error can be another core >>>> class which isn't found. This just adds to the confusion in that the error >>>> isn't consistent. >>>> >>>> For testing, I've set keep_releases to 1 for now - on a couple of sites, >>>> deployments are working fine, but on another, I'm having the issue >>>> described above. The deployment scripts are practically identical. >>>> >>>> >>>> >>>> On Tuesday, 29 January 2013 17:26:33 UTC, dbray wrote: >>>>> >>>>> It should be #{latest_release} not #{release_path} >>>>> >>>>> release_path only works during a deploy; latest_release will work all the >>>>> time. >>>>> >>>>> See: >>>>> >>>>> https://github.com/capistrano/capistrano/blob/master/lib/capistrano/recipes/deploy.rb >>>>> >>>>> Have you ensured that all the targets in shared exist before attempting >>>>> to create the symlinks? >>>>> >>>>> What isn't working about it? >>>>> >>>>> Are you invoking 'cap deploy:shared_symlinks' then see my suggestion >>>>> above. >>>>> >>>>> Is the cap task raising an error; post a copy of a failed run. >>>>> >>>>> Is the task executing but you just don't end up with the symlinks? >>>>> >>>>> Are there files pre-existing in the release directory from checkout; you >>>>> need to remove them in order to recreate them as symlinks. >>>>> >>>>> On Jan 29, 2013, at 3:30 AM, bsod99 <[email protected]> wrote: >>>>> >>>>>> Alas, this still isn't correct - symlinking definitely a bit messed up, >>>>>> Can anyone see what is wrong with this staging.rb script? >>>>>> http://pastie.org/5927281 >>>>>> I must still have the order wrong...thanks for any help >>>>>> >>>>>> >>>>>> On Thursday, 24 January 2013 09:47:59 UTC, bsod99 wrote: >>>>>>> >>>>>>> Thanks for all the replies. I followed dbray's advice and kept releases >>>>>>> at, and adjusted sequencing to: >>>>>>> >>>>>>> after "deploy:update", "deploy:symlink_shared" >>>>>>> after "deploy:restart", "deploy:cleanup" >>>>>>> >>>>>>> This seems to be working fine (and makes sense, having thought through >>>>>>> more carefully about what each is doing) >>>>>>> >>>>>>> On Thursday, 24 January 2013 02:42:51 UTC, dbray wrote: >>>>>>>> >>>>>>>> Keep releases should be 2 at minimum in my opinion >>>>>>>> >>>>>>>> On Jan 23, 2013, at 9:26 AM, bsod99 <[email protected]> wrote: >>>>>>>> >>>>>>>>> I followed the advice in another post about how to clean up old >>>>>>>>> capistrano releases, however, i've realised that the way I've >>>>>>>>> implemented this has messed up the paths in my application (just on a >>>>>>>>> staging site thankfully!). I am using the code below in my >>>>>>>>> config/deploy/staging.rb script, but it can't be running at the >>>>>>>>> correct point, as after deployment I end up with application failing >>>>>>>>> as it's trying to load classes from earlier releases. If I remove the >>>>>>>>> keep_releases line and the one below, and redeploy, everything works >>>>>>>>> again. Has anyone come across this issue? >>>>>>>>> >>>>>>>>> set :use_sudo, false >>>>>>>>> set :keep_releases, 1 >>>>>>>>> after "deploy:update", "deploy:cleanup" >>>>>>>>> >>>>>>>>> namespace :deploy do >>>>>>>>> task :symlink_shared do >>>>>>>>> // run some commands i need >>>>>>>>> end >>>>>>>>> end >>>>>>>>> >>>>>>>>> before "deploy:restart", "deploy:symlink_shared" >>>>>>>>> -- >>>>>>>>> * You received this message because you are subscribed to the Google >>>>>>>>> Groups "Capistrano" group. >>>>>>>>> * To post to this group, send email to [email protected] >>>>>>>>> * To unsubscribe from this group, send email to >>>>>>>>> [email protected] For more options, visit this group at >>>>>>>>> http://groups.google.com/group/capistrano?hl=en >>>>>> >>>>>> -- >>>>>> -- >>>>>> * You received this message because you are subscribed to the Google >>>>>> Groups "Capistrano" group. >>>>>> * To post to this group, send email to [email protected] >>>>>> * To unsubscribe from this group, send email to >>>>>> [email protected] For more options, visit this group at >>>>>> http://groups.google.com/group/capistrano?hl=en >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Capistrano" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>>> >>>> >>>> -- >>>> -- >>>> * You received this message because you are subscribed to the Google >>>> Groups "Capistrano" group. >>>> * To post to this group, send email to [email protected] >>>> * To unsubscribe from this group, send email to >>>> [email protected] For more options, visit this group at >>>> http://groups.google.com/group/capistrano?hl=en >>>> --- >>>> You received this message because you are subscribed to the Google Groups >>>> "Capistrano" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> > -- > -- > * You received this message because you are subscribed to the Google Groups > "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this group at > http://groups.google.com/group/capistrano?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Capistrano" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
