You will need to override the cap variable shared_children in order to omit 'system' from symlink activities during deploy.
On Feb 20, 2013, at 6:36 AM, bsod99 <[email protected]> wrote: > Sorry for the delay on this - should there be something in the shared/pids > folder? mine are always empty (running ls -a). One thing which may or may not > be linked to the issue, is that capistrano is creating a "system" folder, in > shared. The framework I use for my sites also has a system folder, which > contains all the core framework files which are never edited. So my releases > folder would have the following for example: > > app_public > app_admin > public_html > system > modules > > And my shared folder would have > > app_public -> containing some non-versioned config stuff symlinked to currnet > app_admin -> same for this > public_html -> same > cached-copy -> capistrano > log -> capistrano > pids -> capistrano > system -> capistrano > > On Thursday, 7 February 2013 16:44:41 UTC, dbray wrote: >> >> 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. > > -- -- * 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.
