Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a staging server running nginx 1.0.5 using Rails 3.1 under Passenger 3.0.9. The problem is that a request sent just after one where there's an application error return 502 Bad Gateway. To test it I've set up a simple controller with an action that just raise a dummy exception. One request will show the Rails error message and the next one will show nginx 502 Bad Gateway error, then it goes back to the Rails application error, etc.

While investigating this problem I've found out that load testing the application (which increase the number of application processes) make that issue disapear. That is until the extra processes are shutdown, then it reappear. I've tried setting the passenger_min_instances option, but doing so doesn't change anything and in this case each time an application error happen one instance is killed while after load testing all instances are kept alive.

P.S.: Some people on my team told me that they've seen the 502 error even when there's no application error but I've not been able to reproduce that.

Update: Just found out how to display the responses status codes using ab and most of them are 502!

share|improve this question

I've finally found out what is the real problem. First, while investigating this issue I learned that Passanger log it's error messages in the nginx internal error log, not the ones in /var/log, on our server it's located at /usr/local/nginx/logs/error.log. So the actual error message I was getting is:

Exception ThreadError in application (deadlock; recursive locking) (process 6407, thread #<Thread:0x89e5ef0>):
    from /var/www/fantasy-sports/shared/bundle/ruby/1.9.1/gems/rack-1.3.2/lib/rack/lock.rb:14:in `lock'

There's more information about this issue there:

In the end I've resolved it by uncommenting the config.threadsafe! option in the environments/*.rb files.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.