Re: Не понятное поведение при использовании proxy_pass в локейшене

[Alex Domoradov]

В том то и дело, что никто ни reload ни restart не делал. nginx работал с
7го ноября без каких либо вмешательств. И перестал сегодня утром. Попробую
уточнить, когда был удален апстрим в локейшене test

2017-12-07 15:33 GMT+02:00 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Thu, Dec 07, 2017 at 03:01:56PM +0200, Alex Domoradov wrote:
>
> > Понятно, просто изначально проблема была немного другой.
> >
> > В location /test/ не было указано никаких резолверов, и он проксировал на
> > тестовый инстанс elk, который со временем удалили, при этом перестало
> > работать проксирование и на основной elk, который находится в корневом
> > локейшене. Пользователи стали получать - "504 Gateway Time-out". В
> > error.log при этом было
> >
> > 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream "
> > search-testing.us-west-1.es.amazonaws.com" in
> /etc/nginx/conf.d/elk.conf:46
> >
> > Это тоже нормальное поведение, что если в любом из локейшенов в пределах
> > одного сервера, перестает резолвиться апстрим, то перестает работать весь
> > сервер? Я пробовал воспроизвести проблему, но не получилось. Единственное
> > отличие это то, что в первом случае, когда стал не доступен корневой
> > апстрим, с момента запуска nginx до момента возникновения проблемы прошел
> > месяц. Такое ощущение, что сбросились какие то кеши.
>
> Если какое-либо из имён, указанных в конфигурации, не резолвится -
> то это повод отклонить такую конфигурацию.  Приведённая ошибка -
> это как раз ошибка парсинга конфигурации.
>
> Соответственно, если такое происходит при попытке перезагрузить
> конфигурацию - то nginx просто продолжит работать со старой
> конфигурацией.
>
> Если же вы зачем-то сначала остановили nginx, а потом пытаетесь
> запустить его с конфигурацией, в которой указано несуществующее
> имя - то сначала придётся конфигурацию исправить, и только после
> этого nginx запустится.
>
> (Отмечу в скобках, что некоторые по привычке используют restart
> вместо reload при изменениях конфигурации.  Так делать не надо -
> это, во-первых, приводит к потере запросов в момент перезапуска, а
> во-вторых - может привести к полной недоступности сервиса, если
> старый nginx завершится, а новый не сможет стартовать из-за
> каких-то проблем.  Лучше всегда использовать reload, а при
> необходимости обновления исполняемого файла - upgrade.  Такой
> подход позволяет гарантировать, что nginx продолжит работать в
> любых условиях.  Подробнее про всё это написано на странице
> http://nginx.org/ru/docs/control.html.)
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20171207/cb4718d1/attachment-0001.html>