Chapter 8[ 191 ]A critical-level message means that NGINX cannot perform the requested action.
If it was not already running, this means that NGINX would not start.
Here is an example of an emergency message:
2012/10/14 19:12:05 [emerg] 3195#0: bind() to 0.0.0.0:80 failed (98:
Address already in use)
An emergency message also means that NGINX could not do what was requested.
It also means that NGINX won't start, or if it was already running when asked to
read the configuration, it won't perform the requested change.
If you are wondering why your configuration change is not taking
effect, check the error log. NGINX has most likely encountered an
error in the configuration and has not applied the change.Error log file entry examples
The following are some examples of error messages found in real log files. After each
example, a short explanation of what it could mean follows. Please note that the exact
text may be different from what you see in your log files, due to improvements made
in newer releases of NGINX.
Look at the following log file entry example:
2012/11/29 21:31:34 [error] 6338#0: *1 upstream prematurely
closed connection while reading response header from upstream,
client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream:
"fastcgi://127.0.0.1:8080", host: "www.example.com"
Here we have a message that could be interpreted in a couple of ways. It might
mean that the server we are talking to has an error in its implementation, and
does not speak the FastCGI protocol properly. It could also mean that we have
mistakenly directed traffic to an HTTP server, instead of a FastCGI server. If that
is the case, a simple configuration change (using proxypass instead of fastcgi
pass, or using the correct address for the FastCGI server) could fix the problem.
This type of message could also simply mean that the upstream server takes too
long to generate a response. The reason could be due to a number of factors, but
the solution, as far as NGINX is concerned, is fairly simple: increase the timeouts.
Depending on which module was responsible for making this connection, the
proxy_read_timeout or fastcgi_read_timeout (or other *_read_timeout)
directive would need to be increased from the default value of 60s.