On 30.03.2017 22:07, Konstantin Pavlov wrote:

>>> Сколько по времени занимает проверка конфигурационного файла (nginx -t)?
>>
>> Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд.
>> Наверное сказывается нагрузка на диски другими контейнерами сервера.
>>
>> А насколько я понял исходники nginx - он создает pid-файл
>> только после успешного чтения конфигурационного файла. (!)
>>
>> Причина глюка видимо в том, что за секунду ни разу не выполнилось
>> условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что
>> нового ${pidfile} просто еще не было на тот момент на диске.
>
> Да, именно поэтому я и спросил про время.
>
>> Может быть имеет смысл сделать UPGRADEWAITLOOPS побольше, так чтобы
>> максимальное время ожидания было не 1 секунда, а 30 секунд например?
>>
>> Это будет очень актуально для конфигураций с большим количеством
>> включаемых файлов на серверах с нагруженной дисковой подсистемой.
>>
>> А так как сейчас есть - получается race condition.
>> Собственно именно это и наблюдалось в моем случае.
>
> Мы посчитали, что секунды по-умолчанию должно быть достаточно для всех =)
>

Как мне кажется, задержка в 1 секунду пошла из Makefile,
который генерируется командой ./configure из состава nginx:

upgrade:
/usr/local/nginx/sbin/nginx -t

kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
sleep 1
test -f /usr/local/nginx/logs/nginx.pid.oldbin

kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`

Но тут никто не ждет появления pid-файла от нового мастера,
одна секунда дается старому мастеру на то чтобы получить
сигнал, переименовать nginx.pid в nginx.pid.oldbin
и запустить новый мастер (без лимита времени на старт)

В скрипте /usr/libexec/initscripts/legacy-actions/nginx/upgrade
логика теперь уже совсем другая, там ожидается что за 1 секунду
новый мастер успеет прочитать конфиг и записать свой pid-файл.

Когда включается много мелких конфигурационных файлов в основной конфиг
и когда дисковая подсистема сервера загружена - легко может получиться
и 11 секунд и даже больше.

Можно ли увеличить значение по-умолчанию переменной UPGRADEWAITLOOPS
до UPGRADEWAITLOOPS=450 ?

Это вполне безопасно и не будет приводить к каким-либо проблемам.

В том же systemd значением по-умолчанию для TimeoutStartSec=
и TimeoutStopSec= является 90 секунд и это не вызывает никаких проблем.

Тут у нас, по сути, счетчик UPGRADEWAITLOOPS играет роль TimeoutStartSec

> В инит-скрипте для centos/rhel 5-6 используется вот такое для переопределения администраторами:
>
> 30 sysconfig=`/bin/basename $initscript`
> 31
> 32 if [ -f /etc/sysconfig/$sysconfig ]; then
> 33 . /etc/sysconfig/$sysconfig
> 34 fi
>
> ...
>
> 42 UPGRADEWAITLOOPS=${UPGRADEWAITLOOPS-5}
> 43 CHECKSLEEP=${CHECKSLEEP-3}
>
> Соответственно администратор может переназначить значения переменных так, как подходит для его системы.
>
> Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным образом.

Только сделайте, пожалуйста, значение по-умолчанию UPGRADEWAITLOOPS=450

И тогда очень мало кому понадобится менять новое дефолтовое значение
UPGRADEWAITLOOPS=450 на какое-то другое, 99.999999% пользователей
вполне устроит то, как будет работать новый service nginx upgrade

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru