* completely stumped by problem encountered replacing running unicorn
@ 2010-10-14 4:58 Justin Giancola
2010-10-14 5:50 ` Lawrence Pit
0 siblings, 1 reply; 3+ messages in thread
From: Justin Giancola @ 2010-10-14 4:58 UTC (permalink / raw)
To: mongrel-unicorn
Hello,
First off, many thanks to all those who have contributed to this great
project. I have been running Unicorn in production for quite some time
now. It hass been very reliable and I have really enjoyed being able
to deploy frequently without downtime or even dropped connections.
I have used the USR2+QUIT upgrade procedure as described in SIGNALS
since I started using Unicorn and it works great. However, while
upgrading Bundler on my server the other day, an upgrade failed for
the first time. The upgrade failed due to a LoadError -- <application
root>/gems/environment.rb is no longer used in Bundler 1.0 so it was
missing from the new application tree.
I am using a Capistrano setup so my app is located at
/path/to/app/current where current is a symlink to a timestamped
release directory. I am calling #working_directory in my unicorn
config to set it to the symlinked current path. I am also calling
unicorn via a binstub generated by Bundler located at
/path/to/app/current/bin/unicorn.
I had expected that reexec would pick up the new unicorn and app code
because the path to the unicorn executable script, the path to my app,
and config files were all identical to those used in the previous
deploy. However, this is not what is happening. Rather, it looks like
the previous version of the code is trying to reload iteself in the
new app tree where files are missing.
I am having a very difficult time understanding exactly what files are
being reloaded during the reexec. Even my attempts at troubleshooting
where the load error is originating have left me completely baffled.
In the old app gems/environment.rb is required in a few places but
none of those files seem to be reloaded during the reexec. Further, I
cannot get this executable swap to work no matter what I try. I have
even tried getting rid of the symlinks entirely and changing the
contents of the /path/to/app/current in place during the upgrade.
I feel like I may be missing something obvious or else I have
completely misunderstood how the reload process works. Any insight as
to what I should be doing differently would be greatly appreciated.
Justin
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: completely stumped by problem encountered replacing running unicorn
2010-10-14 4:58 completely stumped by problem encountered replacing running unicorn Justin Giancola
@ 2010-10-14 5:50 ` Lawrence Pit
2010-10-14 23:01 ` Justin Giancola
0 siblings, 1 reply; 3+ messages in thread
From: Lawrence Pit @ 2010-10-14 5:50 UTC (permalink / raw)
To: unicorn list
Hi Justin,
See the paragraph "Other ENV pollution issues" at
http://unicorn.bogomips.org/Sandbox.html
Cheers,
Lawrence
> Hello,
>
> First off, many thanks to all those who have contributed to this great
> project. I have been running Unicorn in production for quite some time
> now. It hass been very reliable and I have really enjoyed being able
> to deploy frequently without downtime or even dropped connections.
>
> I have used the USR2+QUIT upgrade procedure as described in SIGNALS
> since I started using Unicorn and it works great. However, while
> upgrading Bundler on my server the other day, an upgrade failed for
> the first time. The upgrade failed due to a LoadError --<application
> root>/gems/environment.rb is no longer used in Bundler 1.0 so it was
> missing from the new application tree.
>
> I am using a Capistrano setup so my app is located at
> /path/to/app/current where current is a symlink to a timestamped
> release directory. I am calling #working_directory in my unicorn
> config to set it to the symlinked current path. I am also calling
> unicorn via a binstub generated by Bundler located at
> /path/to/app/current/bin/unicorn.
>
> I had expected that reexec would pick up the new unicorn and app code
> because the path to the unicorn executable script, the path to my app,
> and config files were all identical to those used in the previous
> deploy. However, this is not what is happening. Rather, it looks like
> the previous version of the code is trying to reload iteself in the
> new app tree where files are missing.
>
> I am having a very difficult time understanding exactly what files are
> being reloaded during the reexec. Even my attempts at troubleshooting
> where the load error is originating have left me completely baffled.
> In the old app gems/environment.rb is required in a few places but
> none of those files seem to be reloaded during the reexec. Further, I
> cannot get this executable swap to work no matter what I try. I have
> even tried getting rid of the symlinks entirely and changing the
> contents of the /path/to/app/current in place during the upgrade.
>
> I feel like I may be missing something obvious or else I have
> completely misunderstood how the reload process works. Any insight as
> to what I should be doing differently would be greatly appreciated.
>
>
> Justin
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: completely stumped by problem encountered replacing running unicorn
2010-10-14 5:50 ` Lawrence Pit
@ 2010-10-14 23:01 ` Justin Giancola
0 siblings, 0 replies; 3+ messages in thread
From: Justin Giancola @ 2010-10-14 23:01 UTC (permalink / raw)
To: unicorn list
Thanks, Lawrence.
ENV pollution was indeed the problem. The aforementioned exception was
being caused by by Bundler 0.7 having set ENV['RUBYOPT'] to
"-r<application root>/gems/environment.rb". After clearing that and
setting my paths properly it worked.
Thank you very much for pointing me in the right direction.
Justin
On Thu, Oct 14, 2010 at 1:50 AM, Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi Justin,
>
> See the paragraph "Other ENV pollution issues" at
> http://unicorn.bogomips.org/Sandbox.html
>
>
> Cheers,
> Lawrence
>
>> Hello,
>>
>> First off, many thanks to all those who have contributed to this great
>> project. I have been running Unicorn in production for quite some time
>> now. It hass been very reliable and I have really enjoyed being able
>> to deploy frequently without downtime or even dropped connections.
>>
>> I have used the USR2+QUIT upgrade procedure as described in SIGNALS
>> since I started using Unicorn and it works great. However, while
>> upgrading Bundler on my server the other day, an upgrade failed for
>> the first time. The upgrade failed due to a LoadError --<application
>> root>/gems/environment.rb is no longer used in Bundler 1.0 so it was
>> missing from the new application tree.
>>
>> I am using a Capistrano setup so my app is located at
>> /path/to/app/current where current is a symlink to a timestamped
>> release directory. I am calling #working_directory in my unicorn
>> config to set it to the symlinked current path. I am also calling
>> unicorn via a binstub generated by Bundler located at
>> /path/to/app/current/bin/unicorn.
>>
>> I had expected that reexec would pick up the new unicorn and app code
>> because the path to the unicorn executable script, the path to my app,
>> and config files were all identical to those used in the previous
>> deploy. However, this is not what is happening. Rather, it looks like
>> the previous version of the code is trying to reload iteself in the
>> new app tree where files are missing.
>>
>> I am having a very difficult time understanding exactly what files are
>> being reloaded during the reexec. Even my attempts at troubleshooting
>> where the load error is originating have left me completely baffled.
>> In the old app gems/environment.rb is required in a few places but
>> none of those files seem to be reloaded during the reexec. Further, I
>> cannot get this executable swap to work no matter what I try. I have
>> even tried getting rid of the symlinks entirely and changing the
>> contents of the /path/to/app/current in place during the upgrade.
>>
>> I feel like I may be missing something obvious or else I have
>> completely misunderstood how the reload process works. Any insight as
>> to what I should be doing differently would be greatly appreciated.
>>
>>
>> Justin
>> _______________________________________________
>> Unicorn mailing list - mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> Do not quote signatures (like this one) or top post when replying
>>
>
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-10-14 23:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-14 4:58 completely stumped by problem encountered replacing running unicorn Justin Giancola
2010-10-14 5:50 ` Lawrence Pit
2010-10-14 23:01 ` Justin Giancola
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).