completely stumped by problem encountered replacing running unicorn

completely stumped by problem encountered replacing running unicorn

[Justin Giancola]

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

Re: completely stumped by problem encountered replacing running unicorn

[Lawrence Pit]

  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

Re: completely stumped by problem encountered replacing running unicorn

[Justin Giancola]

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