Hello! On Mon, Jul 08, 2019 at 04:55:40PM +0300, Slawa Olhovchenkov wrote:
> On Mon, Jul 08, 2019 at 04:29:06PM +0300, Maxim Dounin wrote: > > > > > > есть кусок конфига > > > > > location /pkg { alias /poudriere/data/packages; index index.html > > > > > index.htm; } > > > > > добавляем > > > > > > > > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; } > > > > > nginx -s reload > > > > > > > > > > и призапросе получеам такую ошибку: > > > > > > > > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of > > > > > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: > > > > > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ > > > > > HTTP/1.1", host: "pkg.int.integros.com" > > > > > > > > > > что за фигня? > > > > > а если сделать > > > > > > > > > > /usr/local/etc/rc.d/nginx restart > > > > > > > > > > то все начинает работать > > > > > что за нафиг? > > > > > > > > In no particular order: > > > > > > > > - "nginx -s <action>" и "/usr/local/etc/rc.d/nginx <action>" - не > > > > > > action тут разный. я на этом внимание не заострил, думал и так понятно > > > > Понятно. И также понятно, что даже при одном и том же action - > > приведённые команды делают разное, и результаты могут кардинально > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > эту проблему как на одну из возможных причин наблюдаемого > > поведения. Дабы подобную проблему гарантированно исключить - > > лучше всего использовать одну и ту же форму команды. > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` Зато бывает "service nginx reload" и "service nginx restart". (Ну и вообще, использовать "nginx -s ..." на юникс-системах - странно. Как минимум попадаем на двойной парсинг конфигурации, как максимум - на невозможность использовать эти команды, если PID-файл надо переложить в другое место.) > > [...] > > > > > > - reload может быть невозможен при некоторых изменениях - в > > > > частности, "на лету" нельзя менять путь и levels у кэша, так как > > > > для их изменения требуется повторная загрузка кэша - либо же > > > > > > кэш не менялся, я привел разницу в строках. > > > > С учётом того, что ошибка reload'а нашлась только после явного > > указания на то, что надо искать - мы не знаем, что менялось, а что > > нет. > > > > > > может просто завершиться ошибкой по внешним причинам; ошибки об > > > > этом будут в глобальном логе в процессе перезагрузки конфигурации; > > > > > > а вот тут интересный момент. > > > restart прошел успешно с тем же конфигом. значит конфиг норм, да? > > > а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг > > > поймешь (такой уж лог). > > > > > > 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is > > > not equal to the number of "worker_cpu_affinity" masks, using last mask > > > for remaining worker processes > > > 2019/07/05 19:13:59 [notice] 81052#0: signal process started > > > 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from > > > 81052, reconfiguring > > > 2019/07/05 19:13:59 [notice] 939#0: reconfiguring > > > 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already > > > loaded in /usr/local/etc/nginx/nginx.conf:1 > > > 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of > > > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: > > > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", > > > host: "" > > > > > > ну вот что я должен заключить? вроде emerg. но написанно is already > > > loaded. т.е. фиг с ним? > > > > Уровень emerg - это фатальная ошибка, после таких ошибок парсинг > > конфигурации прекращается. Если бы nginx считал, что проблему > > можно игнорировать - уровень ошибки был бы другой, и, для высоких > > уровней, рядом было бы написано "ignored". > > а alert у нас что? Уровень alert используется для логгирования серьёзных проблем, однако, в отличи от emerg, он не означает, что дальнейшая работа невозможна. > > Что до самой ошибки и того факта, что ломается оно только на > > релоаде, но не на рестарте - то единственный сценарий, который > > приходит в голову, какой-то такой: > > > > - Был загружен модуль, совмещающий в одном so-файле что-то ещё и > > ndk_http_module; > > lua скорее всего. > > > - Файл *.so на диске поменялся, и теперь содержит только что-то ещё, > > а ndk_http_module был добавлен отдельной директивой load_module. > > не исключаю что так и было. > > > - После чего был сделан reload - и привёл к той же ошибке "module > > ... is already loaded", что было проигнорировано. Так > > нет, он не нашел ndk_* символов. > после чего я добавил строку с загрузко ndk_http. Не нашёл символов - в процессе тестирования конфигурации с помощью "nginx -t" и/или при парсинге конфигурации в процессе запуска "nginx -s"? Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет загруженных модулей, и они получают то, что было на диске. И это одна из причин, почему reload не стоит предварять запуском "nginx -t", и не стоит использовать "nginx -s". > > происходит, потому что с помощью reload'а нельзя изменить ранее > > загруженный модуль - so-шка уже в памяти, и при попытке её снова > > открыть - откроется старая so-шка. Чтобы загрузить новые модули > > после изменения их so-файлов на диске - нужно делать upgrade. > > а чего он их тогда полез открывать-то? > меня устроили бы старые модули. В новой конфигурации - новый список модулей, они открываются / загружаются в соответствии с тем, что задано в директивах load_module в конфиге. Поскольку в список добавился ndk - nginx его попытался загрузить, поскольку в результате оказалось загружено два одинаковых модуля - выдал ошибку и откатился на предыдущую конфигурацию. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru