jimmy.soho at gmail.com
Tue Aug 17 23:39:44 EDT 2010
> In your Capistrano deploy tasks, do you create/update the current
> symlink before you send USR2? You should have the symlink updated
> before sending USR2..
Yes I do.
Meanwhile I've been able to indeed reproduce the issue I was seeing if
I prune releases. This is what I do:
- ls /srv/app/releases shows only:
- stop unicorn
- start unicorn
- deploy new release (same code actually)
- unicorn now has a different PID, /proc/31761/cwd does point to the
latest release directory:
/proc/31761/cwd -> /srv/app/releases/20100818024514
- refresh browser, ok, no issue.
- rm -Rf /srv/app/releases/20100818022900
- deploy another new release
nothing in unicorn.stderr.log, but looking in unicorn.stdout.log it mentions:
/srv/app/releases/20100818022900/Gemfile not found
The unicorn process PID hasn't changed, nor has proc/31761/cwd
My /srv/app/current dir now points to the latest release. Which I
guess is wrong as well, as unicorn failed to start with the latest
release; so it (= capistrano) needs to rollback somehow (which is a
If I now peek in /proc/31761/environ then I notice these:
which are all pointing to the working directory I pruned. Hence the
message about Gemfile not found I guess.
Any suggestions how / when to update those environment variables with
> Other folks here may have more experience with Capistrano+Unicorn,
> maybe they have portable recipes they can share.
Maybe it's more a gem and/or bundler thing? Though it seems like a
general issue to me that environment variables can have references to
old working directories, which need to be updated if you restart
Unicorn with USR2 all the time. Is this something Unicorn could
possibly take care off?
More information about the mongrel-unicorn