Opened 8 years ago

Closed 8 years ago

#1063 closed defect (invalid)

wrong status variable

Reported by: AleksKayunov@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.8.x
Keywords: status variable uwsgi Cc:
uname -a: Linux dev0fmall-xxx-1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.8.1
built by gcc 4.7.2 (Debian 4.7.2-5)
built with OpenSSL 1.0.1e 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --with-ipv6


We use nginx+uwsgi stack and see many errors like:

Aug 30 00:00:55 imfmce-va-81-2 uwsgi: Tue Aug 30 00:00:55 2016 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /provisioning/user/f205970b-6a9f-42b5-830f-c2bec9967b32 (ip !!!

I understand that error occurs when client close connection before reading response or by uwsgi_read_timeout, but I don't understand why in access log I cann't see any error, nginx just log 200 OK:

Aug 30 00:00:55 imfmce-va-81-2 provisioning: active     [ 55544 ]  Sync-Wopi-SyncLocksTask hostpilot       73af65e4-5984-4b2c-baf4-c88cf8385898    -       ECDHE-RSA-AES256-GCM-SHA384     GET     /provisioning/user/f205970b-6a9f-42b5-830f-c2bec9967b32 -       0,0,1,0 200     -       1       OK      -       321     515     844

We use next format log line:

log_format ss_log_format "active\t[ \$pid ]\t\$remote_addr\t\$http_user_agent\t\$upstream_http_x_user_identity\t\$http_x_client_id\t\$http_x_request_id\t\$ssl_cipher\t\$request_method\t\$uri\t\$args\t\$upstream_http_x_durations\t\$status\t\$http_x_error_code\t\$connection_requests\t\$request_completion\t\$content_length\t\$request_length\t\$body_bytes_sent\t\$bytes_sent";

I would like you to understand that, we don't need to fix this error, we just need have right access logs.

Attachments (1)

nginx.conf (14.8 KB ) - added by AleksKayunov@… 8 years ago.

Download all attachments as: .zip

Change History (2)

by AleksKayunov@…, 8 years ago

Attachment: nginx.conf added


comment:1 by Maxim Dounin, 8 years ago

Resolution: invalid
Status: newclosed

The $status variable reflects the status code as sent to the client. As long as response headers were sent with status 200, it's expected to contain 200.

On the other hand, $request_completion logged as OK suggests that the request was completed from nginx point of view, that is, not prematurely closed by the client. You may want to check that your backend isn't trying to send more bytes than it claims in the response Content-Length.

Note: See TracTickets for help on using tickets.