On Monday 15 July 2019 23:11:07 Anton Kiryushkin wrote:
> Я прошу прощения, но все же можно ли выдрать по мотивам последнего патча
> хоть что-то еще, что, вероятно, вернул интерпретатор? Не только код, но
> может быть и хоть какое-то сообщение, а-ля дебаг-хардкор-только не в
> продакшн?
> Все exception в коде всегда имеют сообщение, но 500-е коды продолжаются.

Дело в том, что судя по всему там не бросается exception, либо он молча
перехватывается где-то там же в php коде.

Вот пример с исключением. Конфигурация:

{
"listeners": {
"127.0.0.1:8000": {
"pass": "applications/500",
}
},

"applications": {
"500": {
"type": "php 5",
"script": "500.php",
"root": "/home/vbart/Development/tests/"
}
}
}

Содержимое 500.php:

<?php
throw new Exception('test!');

Делаем запрос:

$ curl -i 127.0.0.1:8000
HTTP/1.1 500 Internal Server Error
X-Powered-By: PHP/5.6.38-pl0-gentoo
Content-type: text/html; charset=UTF-8
Server: Unit/1.9.0
Date: Tue, 16 Jul 2019 13:21:52 GMT
Transfer-Encoding: chunked

и видим в логе следующее:

2019/07/16 16:21:35 [notice] 5683#5683 php message: PHP Fatal error: Uncaught exception 'Exception' with message 'test!' in /home/vbart/Development/tests/500.php:2
Stack trace:
#0 {main}
thrown in /home/vbart/Development/tests/500.php on line 2

--
Валентин Бартенев



>
> пн, 15 июл. 2019 г. в 15:51, Валентин Бартенев <vbart@nginx.com>:
>
> > On Sunday 14 July 2019 22:09:01 Anton Kiryushkin wrote:
> > > Валентин, спасибо, за ваш совет, пересобрал Unit и получил довольно
> > > загадочную картину. К примеру.
> > > Вот сообщение в логе Unit:
> > > 2019/07/15 00:02:48.152 [warn] 20971#20971 [unit] #174772: application
> > > returned 500 response
> > >
> > > Окей, идем в лог ошибок php и ищем, что ж было:
> > > [15-Jul-2019 00:02:48 Europe/Moscow] Failed to connect [111]: Connection
> > > refused
> > >
> > > Внимание вопрос. Как тут узнать причину?
> > >
> >
> > Ни в исходниках интерпретатора PHP, ни в исходниках Unit-а нет таких
> > строчек.
> >
> > Следовательно строчка генерируется и пишется самими php скриптами. Имеет
> > смысл
> > сделать grep по всем php скриптам и таким образом найти где именно
> > создается эта
> > строчка и генерируется 500-ый ответ.
> >
> > С php-fpm в данном случае было бы ровно то же самое.
> >
> > --
> > Валентин Бартенев
> >
> >
> >
> > > ср, 3 июл. 2019 г. в 18:47, Валентин Бартенев <vbart@nginx.com>:
> > >
> > > > On Wednesday 03 July 2019 12:47:01 Anton Kiryushkin wrote:
> > > > > Спасибо за ваш ответ.
> > > > >
> > > > > Ответ от php-fpm я мог найти в error-log nginx-a. Ну я не скажу,
> > какую
> > > > > именно. Еще раз, проблема заключается в том, что в логе в access.log
> > > > nginx
> > > > > есть 500-й код ответа. Но причину этого 500-го кода нельзя найти в
> > логе
> > > > > ошибок php (а там прописана опция error_log), и логе unit и в логе
> > nginx,
> > > > > потому что там в принципе не должно быть этих ошибок. В случае с fpm
> > в
> > > > логе
> > > > > ошибок nginx гарантированно причину можно было найти. Приложение не
> > > > > возвращает просто так 500-ю ошибку.
> > > > >
> > > > > Поэтому и возник вопрос, как же можно заставить unit писать лог любых
> > > > своих
> > > > > ошибок в какой-то файл. Ну или куда вообще можно было бы копать, так
> > как
> > > > > возможные вещи, которые есть возможность предпринять в php, на мой
> > > > взгляд,
> > > > > предприняты.
> > > > [..]
> > > >
> > > > В error-log nginx писалось то, что приходило от php-fpm через
> > stderr-канал,
> > > > а тот в свою очередь посылал туда то, что php писал в stderr.
> > > >
> > > > В случае Unit-а весь stderr из php направляется в unit.log и
> > собственно там
> > > > и должен быть.
> > > >
> > > > Могу предложить попробовать собрать php модуль с патчем ниже. В этом
> > > > случае
> > > > всякий раз, когда php-интерпретатор возвращает ответ с 500-ым кодом, в
> > > > unit.log
> > > > будет об этом запись.
> > > >
> > > > 2019/07/03 20:45:02.899 [warn] 14919#14919 [unit] #7: application
> > returned
> > > > 500 response
> > > >
> > > > Это, как минимум, позволит исключить ситуацию, что 500-ую генерирует
> > сам
> > > > Unit
> > > > и не сообщает об этом по какой-то причине.
> > > >
> > > > --
> > > > Валентин Бартенев
> > > >
> > > >
> > > > diff -r 2b068c8361f9 src/nxt_php_sapi.c
> > > > --- a/src/nxt_php_sapi.c Tue Jul 02 16:44:08 2019 +0300
> > > > +++ b/src/nxt_php_sapi.c Wed Jul 03 20:32:38 2019 +0300
> > > > @@ -774,6 +774,10 @@ nxt_php_send_headers(sapi_headers_struct
> > > > status = 200;
> > > > }
> > > >
> > > > + if (status == 500) {
> > > > + nxt_unit_req_warn(req, "application returned 500 response");
> > > > + }
> > > > +
> > > > rc = nxt_unit_response_init(req, status, fields_count, resp_size);
> > > > if (nxt_slow_path(rc != NXT_UNIT_OK)) {
> > > > return SAPI_HEADER_SEND_FAILED;
> > > >
> > > >
> > > > _______________________________________________
> > > > nginx-ru mailing list
> > > > nginx-ru@nginx.org
> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Anton Kiryushkin
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> Best regards,
> Anton Kiryushkin
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru