Re: Тонкости работы FastCGI (phpfpm)
Evgeniy Berdnikov wrote: > On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > > Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я > > помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. > > Или тоже помню неверно? > > Неверно. И вообще это не имеет отношения к GCI, поскольку CGI как протокол > не содержит никаких требований к обработке статуса соединения между > клиентом и web-сервером. Речь и не шла об обработке статуса соединения между клиентом и web-сервером. Под "закрыли stdin CGI-скрипту" я имел в виду, что веб-сервер закрыл соединение между собой и скриптом. Впрочем, как меня уже поправили, и в случае CGI-скрипта скрипт может остаться работать, даже если веб-сервер закрыл соединение с ним. Я этого не знал. Бывало тестировал их даже руками или через пайп - не помню, чтобы хоть один оставался выполняться где-то в фоне, после того как я прервал общение с ним. Вообще очень познавательный был разговор, спасибо всем ответившим. > CGI это интерфейс между сервером и дочерним > процессом. А как ведёт себя сервер по отношению изменениям статусов > пользовательских коннекций -- это особенности его реализации. > > > > В результате о том, что соединение закрыто, php узнаёт, только > > > когда попытка записи ответа в соединение возвращает ошибку. > > > > Спасибо за однозначный и четкий ответ. В документации не хватает, к > > сожалению, чтобы этот момент был четко прописан. > > Вы находили в документации по php прямо противоположное утверждение. > Но насколько оно верно -- это вопрос, по мне так php это маргинальная > субкультура и слепо доверять её грамотам не стоит... Не то чтобы "прямо противоположное". В документации просто не оговорено, что требуются определенные дополнительные условия (попытка чтения или записи скриптом) для перехода в состояние ABORTED. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
21.04.2021 17:45, Slawa Olhovchenkov пишет: > On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > >> Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я >> помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. >> Или тоже помню неверно? > > неверно > ничего со скриптом не случается пока он не будет читать или писать в > закрытый сокет С поправкой на общий лимит работы CGI-приложения, для Апача это: CGIScriptTimeout // This directive limits the length of time to wait for more output from the CGI program. If the time is exceeded, the request and CGI are terminated. Default:value of Timeout directive when unset ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я > помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. > Или тоже помню неверно? неверно ничего со скриптом не случается пока он не будет читать или писать в закрытый сокет ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote: > Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я > помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. > Или тоже помню неверно? Неверно. И вообще это не имеет отношения к GCI, поскольку CGI как протокол не содержит никаких требований к обработке статуса соединения между клиентом и web-сервером. CGI это интерфейс между сервером и дочерним процессом. А как ведёт себя сервер по отношению изменениям статусов пользовательских коннекций -- это особенности его реализации. > > В результате о том, что соединение закрыто, php узнаёт, только > > когда попытка записи ответа в соединение возвращает ошибку. > > Спасибо за однозначный и четкий ответ. В документации не хватает, к > сожалению, чтобы этот момент был четко прописан. Вы находили в документации по php прямо противоположное утверждение. Но насколько оно верно -- это вопрос, по мне так php это маргинальная субкультура и слепо доверять её грамотам не стоит... -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Maxim Dounin wrote: > On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > > > Maxim Dounin wrote: > > > > > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно > > > > > > видеть > > > > > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс > > > > > > процесс > > > > > > PHP завершился, что бы ни делал в этот момент. > > > > > > > > > > > > А в приведенных ссылках обратную задачу пытаются решить. > > > > > > > > > > Прямая задача, как я понимаю, нормально решается только в случае, > > > > > если php-скрипт что-то возвращает клиенту, подробнее тут: > > > > > > > > > > https://www.php.net/manual/en/features.connection-handling.php > > > > > > > > Спасибо, Maxim, очень полезная ссылка. Я в первом письме так и > > > > предполагал, как должно происходить (см. последнюю строчку цитаты): > > > > > > > > "If the remote client disconnects, the ABORTED state flag is turned on. > > > > A remote client disconnect is usually caused by users hitting their STOP > > > > button. [...] You can decide whether or not you want a client disconnect > > > > to cause your script to be aborted. Sometimes it is handy to always have > > > > your scripts run to completion even if there is no remote browser > > > > receiving the output. The default behaviour is however for your script > > > > to be aborted when the remote client disconnects. " > > > > > > > > Другой вопрос, почему в наблюдаемом мной случае это не происходило. > > > > Пойду посмотрю код, может там действительно какой-нибудь > > > > ignore_user_abort стоит. В php.ini уже проверил, > > > > ignore_user_abort => Off => Off > > > > > > Отмечу ещё раз, что всё это работает только в том случае, если > > > php-скрипт что-то возвращает клиенту, и даже в этом случае нужны > > > приседания. > > > > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > > внутри себя, и при этом nginx закрывает соединение со скриптом, > > connection-status в скрипте не перейдет в состояние ABORTED? > > > > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > > connection-status в скрипте всё равно останется NORMAL до попытки > > вернуть клиенту какие-то данные? > > Именно об этом рассказано в комментариях, их стоит почитать. Я их читал. Комментарии к "Connection handling" все очень многолетней давности, и комментаторы больше озабочены обратной задачей: чтобы скрипт доработал после нажатия Стоп в браузере, например закоммитил данные в базу. > > И это логично: чтобы отследить закрытие соединения, нужно явно > проверять статус этого самого соединения или ждать событий на нём. > Это сложно и малореализуемо в рамках php с блокирующимися > вызовами. Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение. Или тоже помню неверно? > > Могли бы сделать явную проверку через какой-нибудь recv(MSG_PEEK) > непосредственно в функции connection_aborted(), но, видимо, не > стали. Ну мало ли, может за 10-15 лет (возраст тамошних комментариев) это реализовали. Потому и спросил. > В результате о том, что соединение закрыто, php узнаёт, только > когда попытка записи ответа в соединение возвращает ошибку. Спасибо за однозначный и четкий ответ. В документации не хватает, к сожалению, чтобы этот момент был четко прописан. > > > > Об этом, в частности, рассказывается в комментариях к > > > описанию connection_aborted(). То есть исходная задача "скрипт > > > ждёт ответа базы 3 часа" - в php просто так не решается. > > > > Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если > > nginx соединение с ним закрыл. > > Да, именно об этом и речь: если скрипт просто ждёт ответа базы, то > php с ним ничего делать не будет и не прибьёт его, что бы не > происходило с соединением. Если что-то выводит пользователю - то > есть шанс. OK. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
