capistrano deploy_symlink fails

问题:

This is my first deployment. I did a cap deploy:setup which worked fine.

Then, when I try to execute cap deploy:update I run into error messages. Something along the lines of

rm: cannot remove `/var/www/app_name/current': Is a directory

Here is my capfile and directory permissions.

http://pastie.org/1189919

In general, what is the best practice as far as deployment user and permissions are concerned? Should I use root or create a different user. If a different user what exact permissions does it need?

Thanks

回答1:

Did you create the directories within /var/www/app_name, or were they created by capistrano?

Regardless, the issue you have is that /var/www/app_name/current should not be a directory - it should be a symlink to the current release within /var/www/app_name/releases/. The failure is caused when capistrano has finished creating the new release folder within /var/www/app_name/releases/, and is trying to symlink /var/www/app_name/current to it.

You might be able to fix your issues by renaming /var/www/app_name/current (so you have a backup if things go wrong), and creating a symlink from /var/www/app_name/current to the most recent release within /var/www/app_name/releases/, and then doing a cap deploy. (Delete your backup of current if this works).

As far as best practice goes whatever you do, do not use root. Instead, set up a user (or use an existing user) that has only permissions to the required directories (didn't read your scripts closely, but probably just /var/www/app_name.

回答2:

To deploy a new release you should invoke cap deploy or cap deploy:migrations, not cap deploy:update.

回答3:

I also have had such errors. A totally normal task of updating source code and restarting the server always seems to have problems at various points of the simple script.

Sometimes it complains that a hash value at github doesn't match some expected value, sometimes it won't update a directory because it already exists, but mostly with it wanting to create things that exist.

Is there no way to force Capistrano and thus the shell commands to just DO IT ? I would at least appreciate it asking me what it should do should it encounter this type of error instead of just failing and rolling back. Especially when it's a simple file operation.

I end up having to delete things manually on the server so that the Capistrano script will run without failing. This is obviously not the way forward.