Custom Query (2297 matches)

Баг - невозможность старта и соответственно использования всех версий Nginx на Windows машинах при большом количестве SSL доменов в файле конфигурации.

Проверены версии 1.2.x и 1.3.x, на других версиях думаю то же самое. Проверены конфигурации SSL - дефолтная из документации, своя и еще куча всяких возможных. SSL key были использованы обычные без пароля, полностью корректные и рабочие (при малом количестве доменов). Конфигурация SSL не имеет значения, мощность Windows сервера так же не имеет значения - проблема везде идентична и упирается в таймаут. Важен сам факт использования SSL (ssl on) и количество доменов.

При использовании SSL и кол-ве доменов больше ~1300 сервер Nginx не запускается с ошибкой: the event "ngx_master_xxx" was not signaled for 5s

Без использования SSL в конфиге сервер стартует даже с 10 тыс. доменов и проблема не наблюдается.

Проблема заключается скорее всего тут (жёстко прописан таймаут): ​http://trac.nginx.org/nginx/browser/nginx/trunk/src/os/win32/ngx_process.c

Строка 87: rc = WaitForMultipleObjects(2, events, 0, 5000);

и потом строки

146        case WAIT_TIMEOUT:case WAIT_TIMEOUT:
147	        ngx_log_error(NGX_LOG_ALERT, cycle->log, 0,
148	                      "the event \"%s\" was not signaled for 5s",
149	                      ngx_master_process_event_name);

Просьба исправить этот критический баг. Сервер просто невозможно использовать. Таймаут должен быть настраиваемым, либо сделайте его очень большим. Либо исправьте SSL, чтобы он не тормозил запуск.

P.S. О баге сообщаю впервые, прошу простить если написано сумбурно.

I think I've found a bug in the DAV module related to body reads. Under 1.2.5, this causes a segfault in the worker handling the request. The patch in 1.2.6 fixes the segfault, but nginx returns a 500 when the PUT could reasonably complete. Applying the supplied patch causes the PUT to complete without issue.

I've attached a sample config as well as a script which can reproduce the issue. The appearance of the bug is sensitive to timing, so generating some load on the server under test can raise the odds that you experience it. (In my VM, PUTing over the network while running a tcpdump is good enough.)

First, open a connection and GET a file. Then, on the same connection, PUT a file. The code to read the body doesn't properly handle the case in which the body is not immediately available. If the read() call returns NGX_AGAIN while reading the body, ngx_http_dav_handler() swallows the return code and returns NGX_DONE. This leaves the request in an inconsistent state (where r->request_body->temp_file is NULL or garbage) and causes the crash or 500. If instead ngx_http_dav_handler() recognizes the return code and returns NGX_AGAIN, the read event gets properly scheduled and the upload completes.

We've been running this patch in production for a little while now, and it seems to work fine.

I haven't had a chance to test this against [4938] as it doesn't look like it was merged back to 1.2.

1.) one should expect that case sensitivity plays no role when using the "stop searching" notation (a '^') for 'location' regex's, but the '^~' prefix works and '^~*' does not.

2.) one can get the '^~' syntax verified at start-up with named captures as per this example:

location ^~ ^(?<epre>.+)?/error(?<efile>\/.+)$ {}

but as soon as you add usage of the named captures, the verification fails at that point (not at the regex itself). however, this does not happen 100% of the time! occasionally, if you have just one (1) named capture; the verification step completes w/o error.

this was discovered when the previous example was working with only the 'epre' capture and began to fail when the 'efile' was added. thereafter, removing the second capture would sometimes verify and sometimes not. seemingly, the problem is positional in its intermittency; since removing the first capture and leaving the second one never verified.

it seems the "stop searching" notation is not well-known/-documented and this may be why this problem is not widely reported.

distro: centos 6.3 perl: 5.16.2