В последних нескольких версиях nginx не перечитывает конфиг по сигналу
HUP (рестарт при этом приводит к запуску нгинх с новым конфигом).
Что-то изменилось, или я что-то делаю не так?
# cat /var/run/nginx.pid
31162
# kill -HUP 31162
# ps auxfw | grep nginx
root 31162 0.0 1.0 50912 26612 ?
# nginx -V
nginx version: nginx/1.5.2
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --with-cc-opt='-D
FD
> Проблема на первом сервере стабильно воспроизводится.
скорее всего - сигнал уходит не тому процессу
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Но как???
pid берется из пид файла, именно из того, который прописан в конфиге.
Сигнал посылается именно этому пиду.
Как он может уйти не туда?
# cat /etc/nginx/nginx.conf | grep pid
pid /var/run/nginx.pid;
Конфиги на обоих серверах однаковые, кроме множества server {}.
14.08.2013 17:07, Dan
> pid берется из пид файла, именно из того, который прописан в конфиге.
> Сигнал посылается именно этому пиду.
а вы еще проверьте - действительно ли под этим pid работает ваш nginx
ну и killall -HUP nginx никто не отменял
___
nginx-ru mailing list
nginx-
On 14.08.2013 14:02, Nick Knutov wrote:
# nginx -V
--with-cc-opt='-DFD_SETSIZE=2048'
массив, заданный FD_SETSIZE используется только в том случае,
когда для обработки соединений используется select()
использовать select() с современными версиями ядер смысла нет.
ведь на Linux nginx всеравно б
ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3.
Что искать в дебаг логе? Я не вижу там никаких признаков получения
сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно
работает.
14.08.2013 17:58, Gena Makhomed пишет:
> On 14.08.2013 14:02, Nick Knutov wrote:
Здравствуйте.
Попробуйте собрать без
--with-file-aio
15 августа 2013 г., 3:30 пользователь Nick Knutov написал:
> ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3.
>
> Что искать в дебаг логе? Я не вижу там никаких признаков получения
> сигнала, однако, например, посылание
On 15.08.2013 2:30, Nick Knutov wrote:
ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3.
Что искать в дебаг логе? Я не вижу там никаких признаков получения
сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно
работает.
если включить отладочный лог - в нем
On 15.08.2013 13:09, Валентин Бартенев wrote:
Что искать в дебаг логе? Я не вижу там никаких признаков получения
сигнала, однако, например, посылание сигналов QUIT и TERM прекрасно
работает.
если включить отладочный лог - в нем видно получение сигналов
и что nginx делает дальше, после получени
А нет ли где в логах "too many open files"?
15 августа 2013 г., 3:30 пользователь Nick Knutov написал:
> ок, собрал то же, что было, с дебагом, нгинх заодним обновил до 1.5.3.
>
> Что искать в дебаг логе? Я не вижу там никаких признаков получения
> сигнала, однако, например, посылание сигналов
Ничего не изменилось.
Заодним, обновил ноду до последнего стабильного OpenVZ ядра, тоже никак
не повлияло.
15.08.2013 11:10, Vadim Lazovskiy пишет:
> Здравствуйте.
>
> Попробуйте собрать без
> --with-file-aio
--
Best Regards,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130
Нет
15.08.2013 17:58, Vadim Lazovskiy пишет:
> А нет ли где в логах "too many open files"?
--
Best Regards,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/ma
о! Я, оказывается, включал дебаг лог на уровне http {}, а не выше.
Действительно есть "too many open files", увеличение
worker_rlimit_nofile решило проблему, спасибо.
15.08.2013 17:58, Vadim Lazovskiy пишет:
> А нет ли где в логах "too many open files"?
>
--
Best Regards,
Nick Knutov
http://kn
14 matches
Mail list logo
