Re: unit и его лог

[Anton Kiryushkin]

Спасибо за ваш ответ.

Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу, какую
именно. Еще раз, проблема заключается в том, что в логе в access.log nginx
есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в логе
ошибок php (а там прописана опция error_log), и логе unit и в логе nginx,
потому что там в принципе не должно быть этих ошибок. В случае с fpm в логе
ошибок nginx гарантированно причину можно было найти. Приложение не
возвращает просто так 500-ю ошибку.

Поэтому и возник вопрос, как же можно заставить unit писать лог любых своих
ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так как
возможные вещи, которые есть возможность предпринять в php, на мой взгляд,
предприняты.

ср, 3 июл. 2019 г. в 12:10, Валентин Бартенев <vbart at nginx.com>:

> On Wednesday 03 July 2019 10:36:52 Anton Kiryushkin wrote:
> > Валентин, подскажите, тогда, пожалуйста.
> >
> > У меня вот есть связка nginx + unit (php).
> > И иногда на сайте получается 500-я ошибка. Логи php пишутся и там кроме
> > огромного количества строчек вида:
> >
> > [03-Jul-2019 10:46:01 Europe/Moscow] Failed to connect [111]: Connection
> > refused
> >
> >
> > Нет больше ничего полезного. Смотрю в лог unit и там тоже нет хоть
> > какого-либо прямого или косвенного сообщения о том, что пошло не так.
> Кроме
> > того, о чем я писал выше.
> > В этом смысле nginx + php-fpm давал более прозрачную картину мира. Есть
> > ошибка - она есть в логе. Тут вот как-то не всегда.
> [..]
>
> А какую ошибку в этом случае писал php-fpm?  Можно пример?
>
> Я бы посмотрел по исходникам php, где она возникает и в каких случаях
> пишется.
>
>
> > Может быть я что-то не знаю или упустил во время настройки? Конфиг unit у
> > меня весьма тривиальный:
> >
> > {
> >     "listeners": {
> >         "127.0.0.1:8091": {
> >                 "application": "direct_php"
> >         }
> >    },
> >    "direct_php": {
> >                 "type": "php5.6",
> >                 "processes": {
> >                         "max": 13,
> >                         "spare": 0
> >                 },
> >
> >                 "user": "www-data",
> >                 "group": "www-data",
> >                 "root": "/data/site.ru/web/",
> >                 "index": "index.php"
> >         }
> >     },
> >     "access_log": "/var/log/nginx/unit_access.log"
> > }
> >
> > Может быть у меня воркеры иногда заканчиваются и эта 500я вовсе не от
> php,
> > а от unit, но почему бы тогда куда-то об этом не сообщать?
> [..]
>
> Unit обычно громко ругается в лог, если что-то пошло не так и он сам был
> вынужден сгенерировать 500-ую ошибку.  Но если 500 код ответа был возвращен
> из приложения нормальным путем, то тут нечего больше добавить.
>
> Также как и php-fpm мы отдаем запрос php интерпретатору, тот генерирует
> какой-то ответ с определенным кодом и отдает его обратно.  Попутно он
> может сам что-то логгировать, но это никак не конролируется со стороны
> SAPI, будь то php-fpm, будь то Unit.
>
> Возможно имеет смысл добавить логгирование о том, что вот мол приложение
> вернуло нам 500, чтобы не возникало вопросов, откуда этот ответ родился.
>
> Стоит учесть, что php-fpm и libphp (которую Unit использует) обычно
> используют
> разные php.ini файлы.  И настройки логгирования и репортинга ошибок там
> могут
> отличаться.  Имеет смысл сделать ревизию используемого с Unit-том php.ini
> на
> предмет соответствующих настроек:
>
> https://www.php.net/manual/en/errorfunc.configuration.php
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190703/ebf72555/attachment.html>