Old nginx configuration files - stops new deploy runs.

[notapatch]

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.

BUG [b6f55be2] Command: ( RBENV_ROOT=/opt/rbenv/ RBENV_VERSION=2.1.1 /usr/bin/env sudo /etc/init.d/nginx reload )
DEBUG [b6f55be2]    Reloading nginx configuration: 
DEBUG [b6f55be2]    Reloading nginx configuration: 
DEBUG [b6f55be2]    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
DEBUG [b6f55be2]    Reloading nginx configuration: 
DEBUG [b6f55be2]    nginx: [emerg] open() "/home/deployer/apps/chic_production/shared/log/nginx.access.log" failed (2: No such file or directory)
DEBUG [b6f55be2]    Reloading nginx configuration: 
DEBUG [b6f55be2]    nginx: configuration file /etc/nginx/nginx.conf test failed

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 ;-)

[bruno-]

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.

[notapatch]

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