Hello! 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 до попытки > вернуть клиенту какие-то данные? Именно об этом рассказано в комментариях, их стоит почитать. И это логично: чтобы отследить закрытие соединения, нужно явно проверять статус этого самого соединения или ждать событий на нём. Это сложно и малореализуемо в рамках php с блокирующимися вызовами. Могли бы сделать явную проверку через какой-нибудь recv(MSG_PEEK) непосредственно в функции connection_aborted(), но, видимо, не стали. В результате о том, что соединение закрыто, php узнаёт, только когда попытка записи ответа в соединение возвращает ошибку. > > Об этом, в частности, рассказывается в комментариях к > > описанию connection_aborted(). То есть исходная задача "скрипт > > ждёт ответа базы 3 часа" - в php просто так не решается. > > Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если > nginx соединение с ним закрыл. Да, именно об этом и речь: если скрипт просто ждёт ответа базы, то php с ним ничего делать не будет и не прибьёт его, что бы не происходило с соединением. Если что-то выводит пользователю - то есть шанс. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru