Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Point Unicorn to current/Gemfile instead of release dir. #39

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

amw
Copy link

@amw amw commented Sep 9, 2014

Without this env variable unicorn master process remembers path to Gemfile of specific release. This causes two problems when reloading unicorn using USR2 signal:

  1. Gems are not refreshed if Gemfile has changed since the release when unicorn was started.
  2. If the release from which unicorn was started is removed due to keep_releases option, unicorn will fail to reload (since that Gemfile is no longer available).

You need to cap stage unicorn:stop && cap stage unicorn:start for this fix to be applied.

Without this env variable unicorn master process remembers path to
Gemfile of specific release. This causes two problems when reloading
unicorn using USR2 signal:

1. Gems are not refreshed if Gemfile has changed since the release when
unicorn was started.
2. If the release from which unicorn was started is removed due to
`keep_releases` option, unicorn will fail to reload (since that Gemfile
is no longer available).

You need to `cap stage unicorn:stop && cap stage unicorn:start`
for this fix to be applied.
@mlineen
Copy link
Member

mlineen commented Sep 9, 2014

Out of curiosity since we've seen this issue before and have had various changes relating to it does your unicorn.rb file have the following defined as shown in the example configuration?

# use correct Gemfile on restarts
before_exec do |server|
  ENV['BUNDLE_GEMFILE'] = "#{app_path}/current/Gemfile"
end

@amw
Copy link
Author

amw commented Sep 9, 2014

No, it does not. I guess that's one way to fix this issue.

I do think that setting the env variable when starting unicorn is safer though. That's what the old capistrano-unicorn gem did and it's the only issue I've had with the migration.

@mlineen
Copy link
Member

mlineen commented Sep 9, 2014

When we were last working on this issue, it seemed that without this defined in the unicorn.rb the USR2 signal still had issues identifying the correct Gemfile on restart. I haven't managed to write a set of tests verifying this however.

@amw
Copy link
Author

amw commented Sep 9, 2014

I don't have a set of tests, but it fixed my production app without adding anything about gemfile to my unicorn.rb. Maybe you were testing without stopping unicorn first?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants