Logging errors from Unicorn
normalperson at yhbt.net
Fri Jun 4 16:06:48 EDT 2010
Peter Kieltyka <peter.kieltyka at nulayer.com> wrote:
> Hey guys,
> I'm running a Rails 3 beta3 application using Ruby 1.9.2-preview3 and
> it has been running fairly well, however every now and then (usually
> when under high load), I see error messages like:
> 2010/06/04 14:34:29 [error] 1884#0: *8844 upstream prematurely closed
> connection while reading response header from upstream, client:
> 220.127.116.11, server: portal.crowdreel.com, request: "GET
> /post/18Vmy HTTP/1.1", upstream:
> host: "crowdreel.com"
> ... a lot of these messages.. this is a pretty heavy duty server with
> lots of ram.
> I have a setup similar to what I read up on github's blog as in: nginx
> -> unicorns via a socket upstream.
> My unicorn.rb file looks like:
> # 16 workers and 1 master
> worker_processes 16
> # Load the app into the master before forking workers for super-fast worker spawn times
> preload_app false
> # Restart any workers that haven't responded in 30 seconds
> timeout 45
> # Listen on a Unix data socket
> listen File.expand_path(File.dirname(__FILE__)+'/../tmp/sockets/unicorn.sock'), :backlog => 2048
> I don't preload the app because I start running into annoying issues
> where my workers use the same db connection, so instead I just have
> them load their own instance, its very fast to start up anyways.
> I've read everything I could on this issue and exhausted Google, which
> leaves me to think the only thing left is some incompatibilities with
> 1.9.2. So I was wondering, how can I get logs from unicorn's
> workers/master to know what is happening to these workers, perhaps
> something is segfaulting?
Set stderr_path in your unicorn config file so Unicorn can log
its errors to a file. Otherwise Unicorn will send all errors to
/dev/null when daemonized.
I shall emphasize the importance of stderr_path if you're using the
default logger configuration in the documentation.
Any chance the "/post/18Vmy" request is hitting your timeout? The only
way you can know is if Unicorn logged its errors. You might also want
to check your Rails log for exceptions, too, as some uncaught errors
may show up there.
More information about the mongrel-unicorn