Nginx Conf

Eric Wong normalperson at
Tue Nov 24 02:19:17 EST 2009

Dylan Stamat <dstamat at> wrote:
> On Nov 22, 2009, at 2:53 PM, Eric Wong wrote:
> > One general thing about the nginx configs I've seen is that they're
> > missing the fail_timeout=0 directive in the "server" lines.
> > 
> > I highly recommend setting it since it's a low cost to try an upstream
> > for nginx, and you can avoid 502 errors in case there's a bug in your
> > app that causes a Unicorn worker to not send a valid HTTP response
> > (including hitting the app timeout).
> Hey Eric,
> Yeah, an nginx.conf in examples/ would be great.
> It's probably going to be the most widely used front for
> Unicorn/Rainbows!, so a sample config with some explanations here and
> there would be awesome.  It was great setting up Unicorn and being
> able to just grab the out of there!

OK, I'll push out an nginx example in a bit, need to make sure things
are adequately explained and linked.

> In terms of the fail_timeout, I haven't seen a nginx.conf with that
> entry yet!  Maybe I'm looking at configuration files on the wrong
> projects ;) So, since the upstream attempts are cheap, the combination
> of a max_fail of 1 and fail_timeout of 0 is ideal?  If the
> fail_timeout was at 10, and all the upstreams timed out, wouldn't it
> restart at the beginning of the round-robin, and not block... or...
> would it actually not retry on any due to the inoperable state?

max_fails doesn't seem to have any effect when fail_timeout=0.  Setting
max_fails=0 means the same thing as fail_timeout=0 in nginx >=0.6.33
(it would segfault before :x)  I've just been using fail_timeout=0
since what seems like forever in nginx...

Reading ngx_http_upstream_round_robin.c again, it appears seems that
fail_timeout/max_fails is supposed to get ignored if *all* upstreams are
failing.  So if you have a single upstream it looks like you're safe
even if your Unicorn master nukes workers.  On the other hand I remember
this not being the case at some point a while back; an entire cluster
got effectively shut down because of it.  Just set fail_timeout=0
and stop worrying about it :)

Eric Wong

More information about the mongrel-unicorn mailing list