Troubleshooting Techniques
[ 192 ]Look at the following log file entry example:
2012/11/29 06:31:42 [error] 2589#0: *6437 client intended to send too
large body: 13106010 bytes, client: 127.0.0.1, server: , request: "POST
/upload_file.php HTTP/1.1", host: "www.example.com", referrer: "http://
http://www.example.com/file_upload.html"
This one is fairly straightforward. NGINX reports that the file could not be uploaded
because it is too large. To fix this problem, raise the value of client_body_size. Keep
in mind that due to encoding, the uploaded size will be about 30 percent greater than
the file size itself (for example, if you want to allow your users to upload files up to
12 MB, set this directive to 16m).
Look at the following log file entry example:
2012/10/14 19:51:22 [emerg] 3969#0: "proxy_pass" cannot have URI part in
location given by regular expression, or inside named location, or inside
"if" statement, or inside "limit_except" block in /opt/nginx/conf/nginx.
conf:16
In this example, we see that NGINX won't start due to a configuration error. The error
message is very informative as to why NGINX won't start. We see that there is a URI
in the argument to the proxy_pass directive in a place where it should not have one.
NGINX even tells us on which line (here 16 ) of which file (/opt/nginx/conf/nginx.
conf) the error occurred.
2012/10/14 18:46:26 [emerg] 2584#0: mkdir() "/home/www/tmp/proxy_temp"
failed (2: No such file or directory)
This is an example of a case where NGINX won't start because it can't perform what
was asked of it. The proxy_temp_path directive specifies a location for NGINX to store
temporary files when proxying. If NGINX cannot create this directory, it won't start,
so ensure that the path leading up to this directory exists.
Look at the following log file entry example:
2012/10/14 18:46:54 [emerg] 2593#0: unknown directive "client_bodytemp
path" in /opt/nginx/conf/nginx.conf:6
We see in the preceding code what may appear to be a puzzling message. We know
that client_body_temp_path is a valid directive, but NGINX does not accept it and
gives an unknown directive message. When we think about how NGINX processes
its configuration file, we realize that this does make sense after all. NGINX is built in
a modular fashion. Each module is responsible for processing its own configuration
context. We therefore conclude that this directive appeared in a part of the
configuration file outside the context of the module that parses this directive.