Opened 9 years ago

Closed 9 years ago

#115 closed defect (invalid)

php-fpm process not killed after timeout / client abort

Reported by: stephan schultchen Owned by: somebody
Priority: minor Milestone:
Component: nginx-core Version: 0.8.x
Keywords: Cc:
uname -a: Linux hostname 2.6.32-220.2.1.el6.x86_64 #1 SMP Thu Dec 22 11:15:52 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/0.8.54
built by gcc 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)
TLS SNI support enabled
configure arguments: --user=nginx --group=nginx --prefix=/usr/share/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 --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-file-aio --with-mail_ssl_module --with-ipv6 --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

Description

hey, i´m running php-fpm + nginx with one problem.

whenever a client closes its browser tab, or when the script takes to long to process and an nginx read timeout accours, the php-fpm process working on this request is not killed.

the two options that should control this in nginx & php (ignore_client_abort / ignore_user_abort) are all set to there default values.

so is this a bug, or am i missing something?

i will attach a sample configuration & php script to reproduce this

Attachments (1)

sample.tgz (1.2 KB ) - added by stephan schultchen 9 years ago.
includes nginx configuration file & sample php file that will create a timeout, the php script will log to stdout & the php_error log

Download all attachments as: .zip

Change History (2)

by stephan schultchen, 9 years ago

Attachment: sample.tgz added

includes nginx configuration file & sample php file that will create a timeout, the php script will log to stdout & the php_error log

comment:1 by Maxim Dounin, 9 years ago

Resolution: invalid
Status: newclosed

In such case nginx will close the connection to a backend (php-fpm in your case). It's not under nginx control how this will be processed by a backend, you may have better luck asking php guys for help. Though quick look into docs suggests your script needs flush() to test for the problem properly:

Notes
PHP will not detect that the user has aborted the connection until an attempt is made to send information to the client. Simply using an echo statement does not guarantee that information is sent, see flush().

Note: See TracTickets for help on using tickets.