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

[Alex Domoradov]

Да, это я знаю. Тогда у меня возникает вопрос

Скорее всего ошибка  host not found in upstream "
search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46
действительно была вызвана попыткой сделать reload/restart. Но раз nginx
работал, значит restart не производился. Возможно действительно был reload.
Но он бы не применился по причине ошибки резолвинга. Сам домен был удален
примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда
перестал открываться ELK(кибана)

Больше никаких ошибок в error.log не было. Тогда не понятно, почему
перестало работать проксирование из корневого локейшена, а возвращалась 504
ошибка? У меня к сожалению не удалось воспроизвести это поведение


> зачастую всякие скрипты вращения логов и тому подобного - делают не
просто странное (скажем, HUP, то есть configuration reload,
  вместо USR1), а очень странное, вплоть до restart'а или даже  просто
остановки сервера без попыток его запустить обратно.

Я глянул, логротейт выглядит вот так

# rpm -ql nginx | grep logrotate | xargs cat
/var/log/nginx/*log {
    create 0644 nginx nginx
    daily
    rotate 10
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
        /etc/init.d/nginx reopen_logs
    endscript
}

сама функция выглядит вот так

reopen_logs() {
    configtest_q || return 6
    echo -n $"Reopening $prog logs: "
    killproc -p $pidfile $prog -USR1
    retval=$?
    echo
    return $retval
}

Вроде как ничего необычного

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

> Hello!
>
> On Thu, Dec 07, 2017 at 05:11:13PM +0200, Alex Domoradov wrote:
>
> > В том то и дело, что никто ни reload ни restart не делал. nginx работал с
> > 7го ноября без каких либо вмешательств. И перестал сегодня утром.
> Попробую
> > уточнить, когда был удален апстрим в локейшене test
>
> Процитированное сообщение об ошибке:
>
> > > > 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 подобным в
> процессе работы не занимается - его тем или иным способом об этом
> попросили.
>
> Как именно и кто попросил - это уже, боюсь, разбираться вам.
> Чтобы было проще - стоит включить логгирование как минимум на
> уровне notice, там, в частности, логгируются все полученные
> nginx'ом сигналы (а начиная с 1.13.0 ещё и указывается PID
> отправившего сигнал процесса, но у вас версия старее).
>
> Отмечу также, что:
>
> - на линуксах часто в процессе обновления пакетов практикуется
>   restart сервиса.  Если пакет для nginx'а сделан криво и не умеет
>   делать upgrade - то обновление пакетов может быть причиной
>   restart'а и всех сопутствующих проблем.
>
> - зачастую всякие скрипты вращения логов и тому подобного - делают
>   не просто странное (скажем, HUP, то есть configuration reload,
>   вместо USR1), а очень странное, вплоть до restart'а или даже
>   просто остановки сервера без попыток его запустить обратно.
>
> --
> 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/20171208/463d1adf/attachment.html>