I just upgrade a server and decide to install latest stable Nginx version, 1.10.
The problem is that I am getting the error bellow on images and js. I do not get this error on all images, and it is random error.
Failed to load resource: net::ERR_SPDY_PROTOCOL_ERROR
I try to use spdy on config but I get a warn and test failed.
nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module
Anyway to use SPDY until HTTP2 is more acceptable on Nginx 1.10? Looking for a simple fix that could be done only on Nginx conf.
I found this patch
https://blog.cloudflare.com/open-sourcing-our-nginx-http-2-spdy-code/
But yesterday I got less spdy errors. And I also had an error on my code when I upgrade server.
Related
I trying to start passenger with SSL on mac os localhost but get this:
nginx: [emerg] invalid number of arguments in "ssl_certificate" directive in (way to config)
everything worked well just before I reinstall mac os from a backup image. All looking same as long as I can see.
Any ideas where to look?
Passenger author here. This probably means you didn't specify --ssl-certificate and --ssl-certificate-key as well. Which Passenger version are you using, what is your exact invocation?
I'm having trouble with setting up Sentry server in HTTPS mode. Every now and then, reasonably often while seemingly random, this error message gets written by Raven (Sentry client) into log files:
Unable to reach Sentry log server: <urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol> (url: https://$(valid_server)/)
Web UI works fine. Vast majority of the messages from Raven are received fine and Sentry processes them into usable output. However, due to these errors, something gets lost from time to time.
I have tried to figure this one out, but dead ends seem to follow another. Basically it seems a lot like this:
Python Requests requests.exceptions.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
But when testing my Sentry server with similar s_client query using TLS 1.2, it leads to a valid session unlike with the example there.
It's also not about this, since SNI isn't used:
python-requests 2.0.0 - [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
I'm not able to reproduce the error coherently. Raven's tests are passed and nothing is acutely wrong, until an error pops up in the log.
My set up is: Raven 4.2.1 in Python 2.7.5, Nginx 1.6.0 as reverse proxy handling HTTPS, and finally Sentry 6.4.4 with default Gunicorn 0.17.4. Nginx configs are pretty much similar to official documentation (http://sentry.readthedocs.org/en/latest/quickstart/nginx.html) with a few alterations due to HTTPS.
I ran into the same issue and got it fixed by installing the following dependencies:
On Ubuntu:
sudo aptitude install libffi-dev
And then via pip:
pip install pyopenssl ndg-httpsclient pyasn1
The problem seems to be that Python 2.X doesn't support SNI (which is needed for TLS) out of the box as explained here.
I am having a weird problem with nginx configuration.
The server doesn't boot if I don't comment this line in nginx.conf
#fastcgi_keep_conn on;
And it is uncommented everytime(overwritten) nginx crashes or if the system reboots
I am not sure if I am missing that module or if I have to install additional packages. Could someone point out the error?
Error in /var/log.nginx/nginx.log
unknown directive "fastcgi_keep_conn" in /etc/nginx/nginx.conf:29
The fastcgi_keep_conn directive appeared in nginx version 1.1.4 (released 20 Sep 2011). So your nginx version is too old, and doesn't support keepalive connections, as well cannot know about the directive.
Please, also note that your nginx is obsolete and not supported. You should update it ASAP.
On Ubuntu with REE 1.8.7, with nginx 0.8.53 manually compiled with the
Passenger 3 module doc installed as per the docs, I get an error in
the nginx error log when nginx starts:
Unable to start the Phusion Passenger watchdog because it encountered
the following error during startup: Unable to start the Phusion
Passenger logging agent: an error occurred while sending startup
arguments: Broken pipe (32) (-1: Unknown error 18446744073709551615)
I assume this means nginx never starts properly. When I try and view
my site after this, I get a 403.
2010/10/22 00:56:47 [error] 13874#0: *1813942 directory index of "/var/
rails/myapp/current/public/" is forbidden, client: 125.197.115.16,
server: new.myapp.fm, request: "GET / HTTP/1.1", host: "new.myapp.fm"
I expect the first is probably causing the second. I haven't had any
luck googling this. Can anyone provide insight or help me
troubleshoot?
I got this after upgrading to Passenger 3.0.1 as I had not changed the version of Passenger specified by passenger_root in /opt/nginx/conf/nginx.conf. You might need to change the line that looks like this to specify the correct version:
passenger_root /usr/lib/ruby/gems/1.8/gems/passenger-3.0.1;
You get told to do this when you install nginx. Hope that helps.
I ran into this problem too, and it was because passenger couldn't find ruby:
tail -f /var/log/nginx/error.log
2011/12/20 00:54:45 [alert] 30300#0: Unable to start the Phusion Passenger watchdog because it encountered the following error during startup: Unable to start the Phusion Passenger helper agent: it seems to have crashed during startup for an unknown reason, with exit code 1 (-1: Unknown error)
* Passenger ERROR (ext/common/ApplicationPool/../SpawnManager.h:220):
Could not start the spawn server: ruby: No such file or directory (2)
Even though ruby was properly listed within the system PATH, it didn't seem to work right until I added:
passenger_ruby = /usr/local/bin/ruby;
(the location of my ruby executable) into the http section of my nginx config.
The problem was that PassengerLoggingAgent wasn't installed when I did 'gem install passenger'. I installed it as per this discussion (by grabbing it from the standalone zip) and everything is fine now: http://groups.google.com/group/phusion-passenger/browse_thread/thread/323dc1c7b0e5ee11
I use nginx along with fastcgi. I see a lot of the following errors in the error logs
readv() failed (104: Connection reset
by peer) while reading upstream and
recv() failed (104: Connection reset
by peer) while reading response header
from upstream
I don't see any problem using the application. Are these errors serious or how to get rid of them.
I was using php-fpm in the background and slow scripts were getting killed after a said timeout because it was configured that way. Thus, scripts taking longer than a specified time would get killed and nginx would report a recv or readv error as the connection is closed from the php-fpm engine/process.
Update:
Since nginx version 1.15.3 you can fix this by setting the keepalive_requests option of your upstream to the same number as your php-fpm's pm.max_requests:
upstream name {
...
keepalive_requests number;
...
}
Original answer:
If you are using nginx to connect to php-fpm, one possible cause can also be having nginx' fastcgi_keep_conn parameter set to on (especially if you have a low pm.max_requests setting in php-fpm):
http|server|location {
...
fastcgi_keep_conn on;
...
}
This may cause the described error every time a child process of php-fpm restarts (due to pm.max_requests being reached) while nginx is still connected to it. To test this, set pm.max_requests to a really low number (like 1) and see if you get even more of the above errors.
The fix is quite simple - just deactivate fastcgi_keep_conn:
fastcgi_keep_conn off;
Or remove the parameter completely (since the default value is off). This does mean your nginx will reconnect to php-fpm on every request, but the performance impact is negligible if you have both nginx and php-fpm on the same machine and connect via unix socket.
Regarding this error:
readv() failed (104: Connection reset by peer) while reading upstream and recv() failed (104: Connection reset by peer) while reading response header from upstream
there was 1 more case where I could still see this.
Quick set up overview:
CentOS 5.5
PHP with PHP-FPM 5.3.8 (compiled from scratch with some 3rd party
modules)
Nginx 1.0.5
After looking at the PHP-FPM error logs as well and enabling catch_workers_output = yes in the php-fpm pool config, I found the root cause in this case was actually the amfext module (PHP module for Flash).
There's a known bug and fix for this module that can be corrected by altering the amf.c file.
After fixing this PHP extension issue, the error above was no longer an issue.
This is a very vague error as it can mean a few things. The key is to look at all possible logs and figure it out.
In my case, which is probably somewhat unique, I had a working nginx + php / fastcgi config. I wanted to compile a new updated version of PHP with PHP-FPM and I did so. The reason was that I was working on a live server that couldn't afford downtime. So I had to upgrade and move to PHP-FPM as seamlessly as possible.
Therefore I had 2 instances of PHP.
1 directly talking with fastcgi (PHP 5.3.4) - using TCP / 127.0.0.1:9000 (PHP 5.3.4)
1 configured with PHP-FPM - using Unix socket - unix:/dir/to/socket-fpm
(PHP 5.3.8)
Once I started up PHP-FPM (PHP 5.3.8) on an nginx vhost using a socket connection instead of TCP I started getting this upstream error on any fastcgi page taking longer than x minutes whether they were using FPM or not. Typically it was pages doing large SELECTS in mysql that took ~2 min to load. Bad I know, but this is because of back end DB design.
What I did to fix it was add this in my vhost configuration:
fastcgi_read_timeout 5m;
Now this can be added in the nginx global fastcgi settings as well. It depends on your set up. http://wiki.nginx.org/HttpFcgiModule
Answer # 2.
Interestingly enough fastcgi_read_timeout 5m; fixed one vhost for me.
However I was still getting the error in another vhost, just by running phpinfo();
What fixed this for me was by copying over a default production php.ini file and adding the config I needed into it.
What I had was an old copy of my php.ini from the previous PHP install.
Once I put the default php.ini from 'shared' and just added in the extensions and config I needed, this solved my problem and no longer did I have nginx errors readv() and recv() failed.
I hope 1 of these 2 fixes helps someone.
Also it can be a very simple problem - there is an infinity cicle somewhere in your code, or an infinity trying to connect an external host on your page.
Some times this problem happen because of huge of requests. By default the pm.max_requests in php5-fpm maybe is 100 or below.
To solve it increase its value depend on the your site's requests, For example 500.
And after the you have to restart the service
sudo service php5-fpm restart
Others have mentioned the fastcgi_read_timeout parameter, which is located in the nginx.conf file:
http {
...
fastcgi_read_timeout 600s;
...
}
In addition to that, I also had to change the setting request_terminate_timeout in the file: /etc/php5/fpm/pool.d/www.conf
request_terminate_timeout = 0
Source of information (there are also a few other recommendations for changing php.ini parameters, which may be relevant in some cases): https://ma.ttias.be/nginx-and-php-fpm-upstream-timed-out-failed-110-connection-timed-out-or-reset-by-peer-while-reading/