using unicorn with logging-rails gem

Yoav Aner yoav at kenhub.com
Fri Nov 30 20:17:49 UTC 2012


Thanks Eric,

I think I might have found a solution :)

There was a hint in the config file I had for the logging-rails gem:

  if defined?(PhusionPassenger)
    PhusionPassenger.on_event(:starting_worker_process) do |forked|
      Logging.reopen if forked
    end
  end

I simply added `Logging.reopen` to the after_fork block and now it
looks like it's working again!

Not sure I still fully (or even partially) understand what's going on
there, but at least it's working.

Thanks again for your help.

Cheers
Yoav

On 30 November 2012 21:05, Eric Wong <normalperson at yhbt.net> wrote:
> Yoav Aner <yoav at kenhub.com> wrote:
>> Hi Eric,
>>
>> Thanks a bunch for getting back so quickly on this.
>>
>> I followed your suggestion and tried with `preload_app = false` and looks
>> like this seems to fix this problem! Any idea what can go wrong when it's
>> set to true or how I can try go about fixing this??
>
> preload_app is false by default because it's the most likely to work
> for all gems.
>
> I suspect there's a shared resource (file/socket) or some cached value
> that's initialized before fork and loses state after forking.
>
> It's a fairly common issue with database libraries
>
>> I haven't yet contacted the logging / logging-rails project. Perhaps that's
>> a good idea. Considering the gem did/does work fine on my dev environment
>> and with phusion passenger (and now it seems also with Unicorn, albeit with
>> preload_app = false), I wasn't sure whether the problem is with this gem or
>> elsewhere.
>>
>> Any tips on how to investigate this further or resolve this, or what
>> information I can give the gem maintainer(s) would be much appreciated.
>
> I would definitely contact the maintainer of logging/logging-rails
> on how to reinitialize any state after forking.


More information about the mongrel-unicorn mailing list