<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">В том то и дело, что никто ни reload ни restart не делал. nginx работал с 7го ноября без каких либо вмешательств. И перестал сегодня утром. Попробую уточнить, когда был удален апстрим в локейшене test<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-07 15:33 GMT+02:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Thu, Dec 07, 2017 at 03:01:56PM +0200, Alex Domoradov wrote:<br>
<br>
> Понятно, просто изначально проблема была немного другой.<br>
><br>
> В location /test/ не было указано никаких резолверов, и он проксировал на<br>
> тестовый инстанс elk, который со временем удалили, при этом перестало<br>
> работать проксирование и на основной elk, который находится в корневом<br>
> локейшене. Пользователи стали получать - "504 Gateway Time-out". В<br>
> error.log при этом было<br>
><br>
> 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream "<br>
> <a href="http://search-testing.us-west-1.es.amazonaws.com" rel="noreferrer" target="_blank">search-testing.us-west-1.es.<wbr>amazonaws.com</a>" in /etc/nginx/conf.d/elk.conf:46<br>
><br>
> Это тоже нормальное поведение, что если в любом из локейшенов в пределах<br>
> одного сервера, перестает резолвиться апстрим, то перестает работать весь<br>
> сервер? Я пробовал воспроизвести проблему, но не получилось. Единственное<br>
> отличие это то, что в первом случае, когда стал не доступен корневой<br>
> апстрим, с момента запуска nginx до момента возникновения проблемы прошел<br>
> месяц. Такое ощущение, что сбросились какие то кеши.<br>
<br>
</span>Если какое-либо из имён, указанных в конфигурации, не резолвится -<br>
то это повод отклонить такую конфигурацию.  Приведённая ошибка -<br>
это как раз ошибка парсинга конфигурации.<br>
<br>
Соответственно, если такое происходит при попытке перезагрузить<br>
конфигурацию - то nginx просто продолжит работать со старой<br>
конфигурацией.<br>
<br>
Если же вы зачем-то сначала остановили nginx, а потом пытаетесь<br>
запустить его с конфигурацией, в которой указано несуществующее<br>
имя - то сначала придётся конфигурацию исправить, и только после<br>
этого nginx запустится.<br>
<br>
(Отмечу в скобках, что некоторые по привычке используют restart<br>
вместо reload при изменениях конфигурации.  Так делать не надо -<br>
это, во-первых, приводит к потере запросов в момент перезапуска, а<br>
во-вторых - может привести к полной недоступности сервиса, если<br>
старый nginx завершится, а новый не сможет стартовать из-за<br>
каких-то проблем.  Лучше всегда использовать reload, а при<br>
необходимости обновления исполняемого файла - upgrade.  Такой<br>
подход позволяет гарантировать, что nginx продолжит работать в<br>
любых условиях.  Подробнее про всё это написано на странице<br>
<a href="http://nginx.org/ru/docs/control.html" rel="noreferrer" target="_blank">http://nginx.org/ru/docs/<wbr>control.html</a>.)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div>