Closed notapatch closed 10 years ago
Hi, this is related to issue #2. I set a todo for myself to investigate the option of moving the nginx config file to the application shared directory.
Btw just deleting the application directory is not a way to "uninstall" an app.. There's other junk on the system that's left out. For example the database and unicorn initializers.
While capistrano and this plugin try to streamline the installation process, "uninstalling" is out of the scope. It still has to be done manually and sensibly (keeping in mind other things on the system are not broken).
I'm just mentioning this out, but I agree steps should be taken to prevent these kind of issues.
Agreed, I shouldn't be 'uninstalling' it in such a manner. :-)
It does look out of scope as Capistrano makes sure there is a hook for deploy:set_shared_assets
at the start of the rollback but doesn't seem to have option of removing shared assets if there are no releases left on the system. For now I suspect I will either have to do your own uninstall task or enjoy ssh sudo privileges for purging the server (!).
Uninstall is a big miss for Capistrano. Uninstall should be a one command process, just like deploy, and no programmer should need to ssh unless things really go haywire. ANYWAY, shame. I'll close as this issue is related to issue 2.
This is the only documentation I've seen on the rollback.
For cap production deploy:rollback, it runs these tasks:
deploy
deploy:starting
[before]
deploy:ensure_stage
deploy:set_shared_assets
deploy:check
deploy:started
deploy:reverting
deploy:revert_release
deploy:reverted
[after]
deploy:rollback_assets
deploy:publishing
deploy:symlink:release
deploy:restart
deploy:published
deploy:finishing_rollback
deploy:cleanup_rollback
deploy:finished
deploy:log_revision
1) Add capistrano-unicorn-nginx to app1. Deploy. Delete only the application directory (~/app1/). 2) Add capistrano-unicorn-nginx to app2. Deploy. Get this error.
app1 will have left a physical configuration file in sites-available and it points to a log file in a directory that no longer exists(~/app1/shared/log/nginx.access.log). Nginx can no longer reload and the deploy hangs. To fix it is simple (delete the unnecessary file /etc/nginx/sites-available/app1_production ).
If the nginx configuration file (app1_production in this case) was kept in app1/shared/config/nginx and symlinked to /etc/nginx/sites-available I think we could have had avoided this error - at the cost of dead symlinks in the sites-available directory.
If there is no acceptable programatic solution for you - then any improved error messages or troubleshooting guide would be useful? I think people will blame you even if they made a mistake in not clearing up the configuration files ;-)