atom feed6 messages in ru.sysoev.nginxRe: Upload module + PHP causes active...
FromSent OnAttachments
SupportJan 15, 2010 11:44 pm 
Valery KholodkovJan 16, 2010 2:06 am.patch
icqhereticFeb 18, 2010 12:24 pm 
Valery KholodkovFeb 19, 2010 1:01 am.patch
Ian PyeFeb 22, 2010 10:18 am 
icqhereticFeb 23, 2010 12:16 pm 
Subject:Re: Upload module + PHP causes active connections to continually increase
From:Valery Kholodkov (vale@grid.net.ru)
Date:Jan 16, 2010 2:06:03 am
List:ru.sysoev.nginx
Attachments:

Support wrote:

Hi all,

I'm developing a site using the upload module v2.0.11 ( from http://www.grid.net.ru/nginx/upload.en.html ) and just turned on the Stub Status module. I noticed that each time I send an upload form, the "active connections" number in the stats increments by one.

For example, if I start up Nginx and visit the status, I get:

Active connections: 1 server accepts handled requests 1 1 1 Reading: 0 Writing: 1 Waiting: 0

After opening the upload form in a new tab, uploading a file, and getting a response from the PHP script, I get:

Active connections: 2 server accepts handled requests 3 3 3 Reading: 0 Writing: 2 Waiting: 0

After uploading another file, I get:

Active connections: 3 server accepts handled requests 4 4 5 Reading: 0 Writing: 3 Waiting: 0

I'm concerned that the "active connections" number keeps increasing (as well as the "writing" number), and never seems to go down. Does this mean that Nginx is holding extra connections (and possibly extra file descriptors) open? I'm wondering if this will be a problem once I deploy the site and the server is running for long periods of time. Could it reach some system maximum of open file descriptors?

I thought it might be a problem with my fastcgi setup, but the active connections number doesn't increase when I visit regular (non-upload) PHP pages. Also, the problem didn't occur when I set @accept (in config below) to redirect to a .txt file instead of a .php file. In that case, the file appears in the upload directory, but I get a 405 error because Nginx rejects POSTs to static files.

The relevant section of my nginx.conf is:

location /accept { upload_pass @accept; upload_store /var/www/fbp/uploads/files; upload_set_form_field "$upload_field_name[name]" "$upload_file_name"; upload_set_form_field "$upload_field_name[content_type]" "$upload_content_type"; upload_set_form_field "$upload_field_name[tmp_file]" "$upload_tmp_path"; upload_aggregate_form_field "$upload_field_name[size]" "$upload_file_size"; upload_pass_form_field "key"; }

location @accept { rewrite ^(.*)$ /accept.php last; }

location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

My accept.php is simply:

<?php die('accept.php'); ?>

After the upload, the files appear in the uploads/files directory, and the text 'accept.php' is properly returned to the browser.

Does anyone know what could cause this, and whether I should be concerned? Any help would be appreciated!

Using this patch or switching off keepalive might solve the problem.

-- Best regards, Valery Kholodkov

diff --git a/Changelog b/Changelog index f6e3dbb..07fe6ca 100644 --- a/Changelog +++ b/Changelog @@ -1,4 +1,7 @@

+Version 2.0.12 + * Fixed bug: keepalive connection was hanging after upload has been completed. + Version 2.0.11 * Fixed bug: rb->buf was uninitiazlied at some execution paths. Found by
Andrew Filonov. * Fixed bug: dummy field would not appear whenever form contains only non-file
fields. diff --git a/ngx_http_upload_module.c b/ngx_http_upload_module.c index 0512772..f711dce 100644 --- a/ngx_http_upload_module.c +++ b/ngx_http_upload_module.c @@ -719,6 +719,10 @@ static ngx_int_t
ngx_http_upload_body_handler(ngx_http_request_t *r) { /* {{{ */ ngx_sprintf(r->headers_in.content_length->value.data, "%O",
r->headers_in.content_length_n) - r->headers_in.content_length->value.data;

+#if defined nginx_version && nginx_version >= 8011 + r->main->count--; +#endif + if(uri->len != 0 && uri->data[0] == '/') { rc = ngx_http_internal_redirect(r, uri, &args); }