Opened 9 years ago
Closed 4 years ago
#502 closed defect (invalid)
Problems with serving content on 1.4.4
|Reported by:||David Krmpotic||Owned by:|
|uname -a:||Linux kaya 2.6.32-5-xen-amd64 #1 SMP Tue Mar 8 00:01:30 UTC 2011 x86_64 GNU/Linux|
nginx version: nginx/1.4.4
built by gcc 4.4.5 (Debian 4.4.5-8)
TLS SNI support enabled
configure arguments: --prefix=/opt/nginx --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --with-cc-opt=-Wno-error --with-pcre=/tmp/passenger.s5hplg/pcre-8.32 --add-module=/usr/local/rvm/gems/ruby-2.0.0-p247/gems/passenger-4.0.35/ext/nginx
after upgrading to Passenger 4.0.35 which installed Ningx 1.4.4 every few days I cannot access my sites (also static ones) - timeout.
I wrote to rackspace and they discovered that it's not a connectivity problem... then I remembered it is probably that update.
I also see that it's the nginx problem because when I restart the service, sites work again.
I learned that it's possible to install nginx 1.5 with Passenger manually and I will do that but first I'd like to know if this is solved in 1.5? If not then I will downgrade.
Change History (9)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
|Status:||new → closed|
From what you describe it looks like Passenger problem. If you think it's an nginx problem, please try to reproduce it without 3rd party modules compiled in, and provide more information. See http://wiki.nginx.org/Debugging for some hints.
follow-up: 4 comment:3 by , 9 years ago
Hmm are you sure because a static page that doesn't go through Passenger is not working either when this happens.
let me know
comment:4 by , 9 years ago
Passenger is known for introducing strange bugs in nginx even when not used.
See here for example: http://mailman.nginx.org/pipermail/nginx/2013-February/037563.html
follow-up: 7 comment:5 by , 9 years ago
Hi Valentin. My name is Hongli Lai, CTO at Phusion and lead developer of Phusion Passenger.
I've just helped David with this problem. It turns out that his problem is caused by neither Nginx nor Passenger, but by a TCP rate limiter in the kernel. Once in a while, his port 80 becomes totally unreachable. TCP handshakes don't complete. Even TCP handshakes from localhost don't work. All Nginx processes seem to be working fine, with the Nginx worker blocking on epoll_wait(). However his /var/log/sys contains messages like these:
[16735593.495494] __ratelimit: 15 callbacks suppressed [16735593.495512] TCP: drop open request from xxxxx/yyy
So David is now contacting Rackspace support for help.
I'd also like to take this opportunity to comment on the thread you linked to, http://mailman.nginx.org/pipermail/nginx/2013-February/037563.html. In the 5 years that Phusion Passenger has supported Nginx, we've never encountered a problem looks like the one described in 037563.html. It seems that the two people in 037563.html were the only ones who have ever seen the problem, but unfortunately they did not respond to our requests for more information. I was hoping that this time, David's problem would shed more light on the same issue as 037563.html. But it turns out to be false alarm.
I fully understand that you, as an Nginx developer, is not keen on debugging problems caused by external modules. However I'm hoping that in the future you could take a more nuanced position w.r.t. Phusion Passenger, because I don't think that two unconfirmed reports count as "known for introducing strange bugs". There are tens of thousands of Phusion Passenger + Nginx users out there for whom Phusion Passenger works fine, e.g. Pixar, New York Times, Apple, Juniper, etc. There are even Nginx Plus customers. Of course, I'm not saying that such bugs don't exist - they *might*.
Unfortunately, the two users in 037563.html got the (wrong) idea that problems were intentionally introduced in the open source version, in favor of the Enterprise version. However, nothing is further from the truth. We take pride in producing high-quality, stable and robust software, regardless of whether we charge for it or not. When it comes to core stability, there are no differences between the open source and Enterprise.
Therefore, instead of linking to 037563.html, I would like to invite you to redirect Phusion Passenger-related issues to our mailing list, https://groups.google.com/forum/#!forum/phusion-passenger. If the problem really is in Phusion Passenger then we'd be happy to solve them. We've discussed with Owen and Andrew about helping Nginx Plus customers who use Passenger Enterprise, but I'd like to stress that the same also applies to Nginx open source users who use Phusion Passenger open source.
And finally, I'd like to note that Phusion Passenger's handler is only activated when
passenger_enabled on is set, similar to how scgi_module, fastcgi_module etc work. Phusion Passenger does not install any per-request hooks unless
passenger_enabled on is explicitly set. It should therefore be impossible for it to affect vhosts that only serve static files. If you are interested, I would like to invite you to review our code. It's MIT licensed and available at https://github.com/phusion/passenger/tree/master/ext/nginx
comment:6 by , 9 years ago
Dear Hongli Lai,
thank you for the troubleshooting and sorry for the vague comment about Phusion Passenger above. In future we will definitely redirect such issues to the Phusion Passenger Google Group.
-- Maxim Konovalov
comment:7 by , 9 years ago
Hi Hongli Lai.
Thank you for investigation of the issue. There are a lot of nginx users who use it in combination with Phusion Passenger, so I'm glad to be wrong. Sorry for hastily complaining on your module.
comment:8 by , 4 years ago
|Status:||closed → reopened|
comment:9 by , 4 years ago
|Status:||reopened → closed|
PS: I didn't install anything on that VPS for a long time and the only thing changed is Passenger+NGINX and since then there are problems.