Re: Тонкости работы FastCGI (phpfpm)

[Victor Sudakov]

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 at fidonet