[BUG?] Nginx hangs when you use try_files, map, request_uri and long url.

Maxim Dounin mdounin at mdounin.ru
Mon Jun 18 20:02:32 UTC 2012


Hello!

On Mon, Jun 18, 2012 at 09:51:31PM +0200, Piotr Karbowski wrote:

> Hi,
> 
> For some reason, when I use long key with Map Module the whole nginx
> seems to hang.
> 
> Some background:
> I have two backends, say old_app and new_app. both have own named
> locations, @new_app and old_app. In order to redirect urls I tried
> to use:
> 
> 	map $request_uri $map_apps {
> 		default @new_app;
> 		/asd @old_app;
> 	}
> 	try_files /not_exist $map_apps;
> 
> And it was working, then I added another key, 70 chars long, with
> commas, - and numbers, like "/foo-bar,123,asd-qwe-asdasdasd"
> 
> since the keyword have 70 chars I had to change default 64 value of
> map_hash_bucket_size, I changed it to 128.
> 
> Now, if I access the '/foo-bar,123,asd-qwe-asdasdasd' url, nginx
> just hangs, firefox return 'connection reset', wget seems to retry
> every 3s with message 'no data'. I cant access any vhost, I cant
> even stop nginx, the workers ignore master, when I nginx -s stop,
> the workers are still alive, when I kill master with sigTERM, the
> workers are still alive, eventualy, after few minutes they starts
> working and support requests or just die.
> 
> The underlaying system is debian6, nginx version 1.1.19 (from
> squeeze-backports), 64bit.
> 
> even if I have only default entry in map, and then access the long
> url, the nginx hangs, but when I hash-out the map and try_files
> lines, I can access the url and see 404 error.
> 
> fwiw I tried to use map since I have about 100 URLs that I want to
> proxy_pass to old_app, rest have to be handled by new_app.

The problem isn't map, the problem is try_files which is broken in 
1.1.19.  Please upgrade to 1.2.0 at least, or apply the following 
patch:

http://trac.nginx.org/nginx/changeset/4601/nginx

Changes with nginx 1.2.0:

    *) Bugfix: a segmentation fault might occur in a worker process if the
       "try_files" directive was used; the bug had appeared in 1.1.19.

Maxim Dounin



More information about the nginx mailing list