Troubleshooting Techniques
[ 190 ]Error log file formats
NGINX uses a couple of different logging functions that produce the error_log
entries. The formats used with these functions take on the following patterns:
For example:
2012/10/14 18:56:41 [notice] 2761#0: using inherited sockets from "6;"
This is an example of informational messages (log level notice). In this case, an nginx
binary has replaced a previously-running one, and was able to successfully inherit the
old binary's sockets.
The error-level logger produces a message like the following:
2012/10/14 18:50:34 [error] 2632#0: *1 open() "/opt/nginx/html/blog"
failed (2: No such file or directory), client: 127.0.0.1, server: http://www.
example.com, request: "GET /blog HTTP/1.0", host: "www.example.com"
Depending on the error, you will see messages from the operating system (such as in
this case), or just from NGINX itself. In this case, we see the following components:
- timestamp (2012/10/14 18:50:34)
- log level (error)
- worker pid ( 2632 )
- connection number ( 1 )
- system call (open)
- argument to the system call (/opt/nginx/html/blog)
- error message resulting from the system call (2: No such file or
directory) - which client made the request resulting in the error (127.0.0.1)
- which server context was responsible for handling the request (www.
example.com) - the request itself (GET /blog HTTP/1.0)
- the Host header sent in the request (www.example.com)
Here is an example of a critical-level log entry:
2012/10/14 19:11:50 [crit] 3142#0: the changing binary signal is ignored:
you should shutdown or terminate before either old or new binary's
process