Yeah sorry... I didn't see 1.3.13 came out the day prior. Either way, glad whatever it was seems to have been fixed before I asked... Upgrading to 1.3.13 and the occasional segfaults stopped.by digitalpoint - Nginx Mailing List - English
It's a fairly vanilla install of nginx (with the exception of the SPDY patch). We are seeing roughly 1 segfault every hour or so on each web server... I didn't generate a debugging log, because I wasn't sure how big something like that would be for an entire hour, but I can if needed. ------- nginx -V ------- nginx version: nginx/1.3.12 built by gcc 4.5.1 20101208 (SUSE Linux) TLS SNIby digitalpoint - Nginx Mailing List - English
Valentin V. Bartenev Wrote: ------------------------------------------------------- > On Monday 28 January 2013 23:20:27 digitalpoint wrote: > > Valentin V. Bartenev Wrote: > > ------------------------------------------------------- > > > > > Please, try the new patch: > > > http://nginx.org/patches/spdy/patch.spdy-59_1.3.11.txt > > > >by digitalpoint - Nginx Mailing List - English
Valentin V. Bartenev Wrote: ------------------------------------------------------- > Please, try the new patch: > http://nginx.org/patches/spdy/patch.spdy-59_1.3.11.txt > > The problem should be fixed now. > > wbr, Valentin V. Bartenev Is there a possibility the patch introduced an issue where connections don't expire (like ever)? Our load balancer in front of wby digitalpoint - Nginx Mailing List - English
So far so good... seems to be working fine. :)by digitalpoint - Nginx Mailing List - English
Yeah... the problem is that while it might not be part of the SPDY 2 draft to share connections across multiple hosts, Chrome most certainly is doing it (and probably other browsers) as you can see from the previous screenshot. Either way, you guys are doing a crazy awesome job... keep it up. :)by digitalpoint - Nginx Mailing List - English
Well... the underlying errors went away, but it seems the new SPDY patch broke being able to handle multiple hosts on the same SPDY connection now (it worked under 1.3.10 just fine). For example, we have a SSL cert for both digitalpoint.com and dpstatic.com (dpstatic.com is a cookieless domain for serving static content), so SPDY attempts to use the same connection for multiple hosts. See SPDYby digitalpoint - Nginx Mailing List - English
Here ya go: http://www.shawnhogan.com/error.log.gzby digitalpoint - Nginx Mailing List - English
Nope... still same issue. nginx version: nginx/1.3.11 built by gcc 4.5.1 20101208 (SUSE Linux) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/usr/log/ngnix/error.log --http-log-path=/usr/log/ngnix/access.log --with-openssl=/home/software_source/openssl-1.0.1c --with-cc-opt='-I /usr/local/ssl/incluby digitalpoint - Nginx Mailing List - English
ya sorry, was just coming back to follow up with that... after I posted that, I was wondering why in the hell I was compiling with SSI module... it's actually WITHOUT SSI. :) This is back on 1.3.10 after I rolled it back after the issues: nginx version: nginx/1.3.10 built by gcc 4.5.1 20101208 (SUSE Linux) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usby digitalpoint - Nginx Mailing List - English
Has anyone else seen problems with Nginx with 1.3.11? Everything works perfectly fine with same compile options under 1.3.10... It's a pretty vanilla compile as far as modules... proxy, SSI, SSL and status modules. Using SPDY patch (using the correct patch for each version of Nginx) (and the correct SPDY module compile option on 1.3.11)... RIght right 1.3.11 starts being used, we get this stuby digitalpoint - Nginx Mailing List - English
Thanks... that patch seems to have fixed it. I haven't done exhaustive testing, but if the crypt_r()/internal server errors pop up again, I'll post back here.by digitalpoint - Nginx Mailing List - English
When viewing a page that is HTTP auth password protected, we sometimes get an error 500 (internal server error), but 100% of the time, a browser reload of the page makes it work the second time around. The ngnix error log shows this: 2012/12/19 15:50:43 28799#0: *6224 crypt_r() failed (2: No such file or directory), client: 108.199.xxx.xxx, server: dev.digitalpoint.com, request: "GET /adby digitalpoint - Nginx Mailing List - English