Hello! On Tue, Jul 09, 2019 at 12:07:52PM +0300, Slawa Olhovchenkov wrote:
> On Tue, Jul 09, 2019 at 11:51:19AM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote: > > > > > On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote: > > > > > > > > > > action тут разный. я на этом внимание не заострил, думал и так > > > > > > > понятно > > > > > > > > > > > > Понятно. И также понятно, что даже при одном и том же action - > > > > > > приведённые команды делают разное, и результаты могут кардинально > > > > > > отличаться в том числе из-за этого. Именно поэтому я и указал на > > > > > > эту проблему как на одну из возможных причин наблюдаемого > > > > > > поведения. Дабы подобную проблему гарантированно исключить - > > > > > > лучше всего использовать одну и ту же форму команды. > > > > > > > > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start` > > > > > > > > Зато бывает "service nginx reload" и "service nginx restart". > > > > > > > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - > > > > странно. Как минимум попадаем на двойной парсинг конфигурации, > > > > как максимум - на невозможность использовать эти команды, если > > > > PID-файл надо переложить в другое место.) > > > > > > набирать короче, давно заучил, а эти service вечно меняются... > > > > Форма "service <name> <action>" работает начиная с FreeBSD 7.3, и > > с момента появления не менялась. > > есть еще линуксы в разных вариантах и они сбивают. > а у них еще и имя сервиса различается в зависимости от пакета. > ну и я с фрей работаю начиная с 2.0.5 :) Если подходить к проблеме с точки зрения "есть ещё", то "nginx -s" вообще непоняно что делает, потому что a) nginx может быть более чем один, и б) в скриптах запуска может быть всяких опций прописано, включая другой конфиг. > > > > > > - После чего был сделан reload - и привёл к той же ошибке "module > > > > > > ... is already loaded", что было проигнорировано. Так > > > > > > > > > > нет, он не нашел ndk_* символов. > > > > > после чего я добавил строку с загрузко ndk_http. > > > > > > > > Не нашёл символов - в процессе тестирования конфигурации с помощью > > > > "nginx -t" и/или при парсинге конфигурации в процессе запуска > > > > "nginx -s"? > > > > > > вот тут не помню. > > > > > > > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет > > > > загруженных модулей, и они получают то, что было на диске. И это > > > > одна из причин, почему reload не стоит предварять запуском "nginx -t", > > > > и не стоит использовать "nginx -s". > > > > > > ничего не понял. > > > > В рассматриваемом случае содержимое бинарных файлов на диске > > (nginx + модули) - поменялось. Более того, поменялось - > > несовместимо, для работы старых бинарных файлов требовалась одна > > конфигурация, для работы новых - другая. > > > > Когда такое происходит, использование "nginx -t" и "nginx -s > > <action>" совместно с перезагрузкой конфигурации на лету - > > невозможно. Проблема в том, что эти команды требуют конфигурацию, > > совместимую с новыми бинарными файлами, тогда как для перезагрузки > > конфигурации работающего nginx'а - нужна конфигурация, совместимая > > со старыми бинарными файлами. > > > > Проще всего - в такую ситуацию не попадать, и после обновления > > бинарных файлов (что самого nginx'а, что модулей) - сразу делать > > upgrade, синхронизируя бинарники на дисках, и в памяти. Но вообще > > говоря работа в несинхронизированном состоянии тоже возможна - > > просто надо пользоваться сигналами, а не пытаться использовать > > nginx с диска (который не совпадает с тем, что в памяти). > > так, т.е. nginx -s reload не эквивалентно kill -HUP `cat /var/run/nginx.pid`? > и вторая комманда срабоатла бы по старому варианту конфига и не стала > бы ругаться на неопределенные символы? Именно так. Команда "nginx -s reload" сначала парсит конфиг, чтобы найти путь к этому самому /var/run/nginx.pid - и на этом пути делает много лишней (но неизбежной) работы, в частности - ругается, встретив неправильную с её точки зрения конфигурацию. Впрочем, завести привычку после обновления модулей делать upgrade (равно как и после обновления самого nginx'а) - в любом случае стоит. Если upgrade не сделать, а продолжать работать с тем, что в памяти, то при перезагрузке машины, например, может случиться неприятный сюрприз. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
