On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > внутри себя, и при этом nginx закрывает соединение со скриптом, > connection-status в скрипте не перейдет в состояние ABORTED?
В скрипте (пользовательском процессе с php) не существует connection-status. Статус коннекции есть в ядре, и для закрытой с одной стороны коннекции он будет "half closed", т.е. на стороне получателя FINa перейдёт в состояние CLOSE_WAIT. Смотрите диаграмму состояний TCP в RFC 793. > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > connection-status в скрипте всё равно останется NORMAL до попытки > вернуть клиенту какие-то данные? Повторю: состояние коннекции находится в ядре. Есть интерфейс общения процесса и ядра. Если процесс попытается написать в сокет, для которого другая сторона закрыла коннекцию, то ему ядро вернёт ECONNRESET. > > Об этом, в частности, рассказывается в комментариях к > > описанию connection_aborted(). То есть исходная задача "скрипт > > ждёт ответа базы 3 часа" - в php просто так не решается. > > Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если > nginx соединение с ним закрыл. Для мониторинга состояния коннекции есть poll/epoll/kqueue/etc, как уже писали в этом треде. Но делать такой мониторинг непросто: нужно ловить событие "коннекция закрыта с той стороны" и писать его обработчик, возможно искать способы безопасного прерывания кода, работающего 3 часа. -- Eugene Berdnikov _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru