Stub_status always give me 0 Reading when upgraded to 1.4.1

Server NGINX
1

Hi,

We have upgraded one of our nginx from 0.7.65 to 1.4.1 (keeping existing
configuration) and the stub_status module now always give me “0 Reading”

0.7.65
Active connections: 4798
server accepts handled requests
1690444496 1690415734 1814927218
Reading: 573 Writing: 184 Waiting: 4041

1.4.1
Active connections: 4858
server accepts handled requests
33056255 33056255 37277559
Reading: 0 Writing: 196 Waiting: 4386

They are both installed using Ubuntu package on 10.04 (1.4.1-1ppa1~lucid
, 0.7.65-1ubuntu2.3)

nginx version: nginx/0.7.65
TLS SNI support enabled
configure arguments: --conf-path=/etc/nginx/nginx.conf
–error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid
–lock-path=/var/lock/nginx.lock
–http-log-path=/var/log/nginx/access.log
–http-client-body-temp-path=/var/lib/nginx/body
–http-proxy-temp-path=/var/lib/nginx/proxy
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi --with-debug
–with-http_stub_status_module --with-http_flv_module
–with-http_ssl_module --with-http_dav_module
–with-http_gzip_static_module --with-http_realip_module --with-mail
–with-mail_ssl_module --with-ipv6
–add-module=/build/buildd/nginx-0.7.65/modules/nginx-upstream-fair

nginx version: nginx/1.4.1
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx
–conf-path=/etc/nginx/nginx.conf
–error-log-path=/var/log/nginx/error.log
–http-client-body-temp-path=/var/lib/nginx/body
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi
–http-log-path=/var/log/nginx/access.log
–http-proxy-temp-path=/var/lib/nginx/proxy
–http-scgi-temp-path=/var/lib/nginx/scgi
–http-uwsgi-temp-path=/var/lib/nginx/uwsgi
–lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
–with-pcre-jit
–with-debug --with-http_addition_module --with-http_dav_module
–with-http_geoip_module --with-http_gzip_static_module
–with-http_image_filter_module --with-http_realip_module
–with-http_stub_status_module --with-http_ssl_module
–with-http_sub_module --with-http_xslt_module --with-ipv6 --with-mail
–with-mail_ssl_module
–add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-auth-pam
–add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-dav-ext-module
–add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-echo
–add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-upstream-fair
–add-module=/build/buildd/nginx-1.4.1/debian/modules/ngx_http_substitutions_filter_module

Any idea?

Best Regards,
tszming

2

Hi,

On Wed, Jul 17, 2013 at 6:29 PM, Maxim D. [email protected]
wrote:

stub_status

Thanks for the explanation.

But given that this is a busy server, sound abnormal if it always return
a
0? (according to the doc: reading - nginx reads request header)

Best Regards,
tszming

3

Hello!

On Wed, Jul 17, 2013 at 10:34:48AM +0800, Tsz Ming WONG wrote:

1.4.1
Active connections: 4858
server accepts handled requests
33056255 33056255 37277559
Reading: 0 Writing: 196 Waiting: 4386

This is an effect from the following change in 1.3.15:

*) Change: opening and closing a connection without sending any data

in
it is no longer logged to access_log with error code 400.

Connections in question no longer have an associated request
created, and as a result are counted in “waiting” instead of
“reading”.

–
Maxim D.
http://nginx.org/en/donation.html

4

On Wed, Jul 17, 2013 at 06:48:53PM +0800, Tsz Ming WONG wrote:

Hi,
On Wed, Jul 17, 2013 at 6:29 PM, Maxim D. <[1][email protected]>
wrote:

 stub_status

Thanks for the explanation.
But given that this is a busy server, sound abnormal if it always return a
0? (according to the doc: reading - nginx reads request header)

It means that your clients and nginx are fast enough, enjoy. If you
absolutely need it to become non-zero, you can emulate a slow client
like this:

( echo ‘GET / HTTP/1.0’ ; sleep 42 ; echo ) | nc 127.0.0.1 80

substituting the address and port of your server. During these 42
seconds, the status will show at least one connection in the
“reading” state.

5

Thank you (and Maxim) for the detail explanation!

Best Regards,
tszming

6

Hello!

On Wed, Jul 17, 2013 at 06:48:53PM +0800, Tsz Ming WONG wrote:

Thanks for the explanation.

But given that this is a busy server, sound abnormal if it always return a
0? (according to the doc: reading - nginx reads request header)

Reading request headers happens almost immediately, especially if
request headers fit into a single packet. That is, the number is
expected to be near 0 even on a busy system unless there are some
specific conditions like big cookies used.

–
Maxim D.
http://nginx.org/en/donation.html