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
Re: Тонкости работы FastCGI (phpfpm)
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
Re: Тонкости работы FastCGI (phpfpm)
On Fri, Apr 16, 2021 at 02:27:53PM +0700, Victor Sudakov wrote: > Evgeniy Berdnikov wrote: > > В скрипте (пользовательском процессе с php) не существует > > connection-status. > > А в https://www.php.net/manual/en/features.connection-handling.php > написано что существует. ... > В документации написано, что когда "remote user hits his STOP button, > the next time your script tries to output something PHP will detect that > the connection has been aborted and the shutdown function is called." > > Из этого можно заключить, что если не пытаться что-то из скрипта > выводить, то ABORTED никогда не наступит. Это верное утверждение? Это верный признак того, что к тому что написано на этой страничке нужно относиться с большой осторожностью, раз уж там разные абзацы между собой в противоречии. Главное на этой страничке вот что: The default behaviour is however for your script to be aborted when the remote client disconnects. [...] If you do not tell PHP to ignore a user abort and the user aborts, your script will terminate. Теоретически это реализуемо, так что предлагаю проверить утверждение на чистой инсталляции php со скриптом-пустышкой, уходящим в сон на 3 часа, и если написанное выполняется, то разбираться далее с боевыми скриптами. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Evgeniy Berdnikov wrote: > On Fri, Apr 16, 2021 at 12:54:21PM +0700, Victor Sudakov wrote: > > А если php-скрипт ничего не возвращает клиенту, а делает sleep(100500) > > внутри себя, и при этом nginx закрывает соединение со скриптом, > > connection-status в скрипте не перейдет в состояние ABORTED? > > В скрипте (пользовательском процессе с php) не существует connection-status. А в https://www.php.net/manual/en/features.connection-handling.php написано что существует. > Статус коннекции есть в ядре, и для закрытой с одной стороны коннекции > он будет "half closed", т.е. на стороне получателя FINa перейдёт в > состояние CLOSE_WAIT. Смотрите диаграмму состояний TCP в RFC 793. Это в данном случае не важно. Я говорю о connection status, который доступен в PHP, на уровне приложения, по ссылке выше. > > > Предположим что nginx закрывает TCP-соединение с апстримом штатно (FIN > > -> FIN+ACK -> ACK). Или оно вообще было через Unix-socket. Таки > > connection-status в скрипте всё равно останется NORMAL до попытки > > вернуть клиенту какие-то данные? > > Повторю: состояние коннекции находится в ядре. Есть интерфейс общения > процесса и ядра. Если процесс попытается написать в сокет, для которого > другая сторона закрыла коннекцию, то ему ядро вернёт ECONNRESET. Понятно что php откуда-то узнаёт информацию о состоянии соединения, но с точки зрения php there are 4 possible states: 0 - NORMAL 1 - ABORTED 2 - TIMEOUT 3 - ABORTED and TIMEOUT When a PHP script is running normally, the NORMAL state is active. 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. Вот PHP эти состояния переключает на основе какой-то информации, скорее всего действительно от ядра. Когда состояние становится ABORTED, скрипт должен по идее завершиться. В документации написано, что когда "remote user hits his STOP button, the next time your script tries to output something PHP will detect that the connection has been aborted and the shutdown function is called." Из этого можно заключить, что если не пытаться что-то из скрипта выводить, то ABORTED никогда не наступит. Это верное утверждение? > Для мониторинга состояния коннекции есть poll/epoll/kqueue/etc, как уже > писали в этом треде. Но делать такой мониторинг непросто: нужно ловить > событие "коннекция закрыта с той стороны" и писать его обработчик, Диаграмма состояний TCP и прочие его тонкости в контексте данной беседы без надобности. Можно вообще оговорить, что FastCGI через Unix socket работает, суть вопроса не изменится. > возможно искать способы безопасного прерывания кода, работающего 3 часа. Для этого уже предусмотрели shutdown function, насколько я понимаю. Вопрос не в этом, а в реакции php-fpm на нажатие пользователем кнопки Стоп в браузере - в какой момент это нажатие отразится в состояние 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)
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
Re: Тонкости работы FastCGI (phpfpm)
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_aborted(). То есть исходная задача "скрипт > ждёт ответа базы 3 часа" - в php просто так не решается. Исходная как раз чтобы php-скрипт ничего не ждал и помирал побыстрее, если nginx соединение с ним закрыл. -- 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)
Hello! On Thu, Apr 15, 2021 at 12:02:31PM +0700, Victor Sudakov wrote: > Maxim Dounin wrote: > > > > On Tue, Apr 13, 2021 at 02:52:00PM +0700, Victor Sudakov wrote: > > > > > Aleksandr Sytar wrote: > > > > > > > > > Что должно > > > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код > > > > > продолжит > > > > > работу? Или должен прерваться? > > > > > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > > > Двас - > > > > https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > > > > крути себе дальше в базе что надо. > > > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > > 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-скрипт что-то возвращает клиенту, и даже в этом случае нужны приседания. Об этом, в частности, рассказывается в комментариях к описанию connection_aborted(). То есть исходная задача "скрипт ждёт ответа базы 3 часа" - в php просто так не решается. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
greenh wrote: > вт, 13 апр. 2021 г. в 13:28, Victor Sudakov : > > > greenh wrote: > > > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > > > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, > > его > > > процесс останется запущен, сокет, который он слушает останется активным и > > > процессы внутри его продолжат работу. > > > > Почему бы сокет останется активным, если nginx закрыл соединение к > > апстриму? Или nginx не закрывает соединение к апстриму, когда "браузер > > сдох"? > > > Сокет останется открытым, а не соединение Не понял поправку, можно пояснить мысль? -- 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)
Maxim Dounin wrote: > > On Tue, Apr 13, 2021 at 02:52:00PM +0700, Victor Sudakov wrote: > > > Aleksandr Sytar wrote: > > > > > > > Что должно > > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > > > работу? Или должен прерваться? > > > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > > > крути себе дальше в базе что надо. > > > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > > 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 > https://www.php.net/manual/en/function.ignore-user-abort.php > https://www.php.net/manual/en/function.connection-aborted.php > > Но я не настоящий сварщик, про php знаю мало. > > > Антиоффтопик. nginx-то что делает в момент закрытия соединения > > клиентским браузером: закрывает ли соответствущее соединение с fastcgi > > upstream-ом? > > В общем случае да. И именно для того, чтобы бэкенд узнал о том, > что соединение закрыто клиентом и выполняемая работа больше не > нужна. Так и предполагал. > Если этого по каким-то не требуется, то можно использовать > директиву fastcgi_ignore_client_abort: > > http://nginx.org/r/fastcgi_ignore_client_abort > > Кроме того, соединение не будет закрыто, если используется > кэширование или fastcgi_store, так как в этих случаях ответ > бэкенда полезен вне зависимости от того, будет ли он отправлен > конкретному клиенту. А может и кэширование причиной. Но стало понятнее, куда копать, спасибо еще раз. -- 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)
Slawa Olhovchenkov wrote: > On Tue, Apr 13, 2021 at 02:46:57PM +0700, Victor Sudakov wrote: > > > greenh wrote: > > > Nginx закроет соединение, а php код будет работать до того момента, пока > > > не > > > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - > > > то безконечно. > > > > Вот это плохо. > > > > А почему так? Ведь обычная программа (не демон), как правило, > > завершается или хотя бы останавливается, если ей каналы ввода-вывода > > закрыли. > > да нет же. > это твои влажные фантазии. Слава, грубить-то зачем? Не с той ноги встал? -- 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)
Добрый день, > Кроме того, соединение не будет закрыто, если используется > кэширование или fastcgi_store, так как в этих случаях ответ > бэкенда полезен вне зависимости от того, будет ли он отправлен > конкретному клиенту. вот это уточнение прямо очень интересное, спасибо за него, Максим! ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Hello! On Tue, Apr 13, 2021 at 02:52:00PM +0700, Victor Sudakov wrote: > Aleksandr Sytar wrote: > > > > > Что должно > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > > работу? Или должен прерваться? > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > > крути себе дальше в базе что надо. > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > PHP завершился, что бы ни делал в этот момент. > > А в приведенных ссылках обратную задачу пытаются решить. Прямая задача, как я понимаю, нормально решается только в случае, если php-скрипт что-то возвращает клиенту, подробнее тут: https://www.php.net/manual/en/features.connection-handling.php https://www.php.net/manual/en/function.ignore-user-abort.php https://www.php.net/manual/en/function.connection-aborted.php Но я не настоящий сварщик, про php знаю мало. > Антиоффтопик. nginx-то что делает в момент закрытия соединения > клиентским браузером: закрывает ли соответствущее соединение с fastcgi > upstream-ом? В общем случае да. И именно для того, чтобы бэкенд узнал о том, что соединение закрыто клиентом и выполняемая работа больше не нужна. Если этого по каким-то не требуется, то можно использовать директиву fastcgi_ignore_client_abort: http://nginx.org/r/fastcgi_ignore_client_abort Кроме того, соединение не будет закрыто, если используется кэширование или fastcgi_store, так как в этих случаях ответ бэкенда полезен вне зависимости от того, будет ли он отправлен конкретному клиенту. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
On Tue, Apr 13, 2021 at 02:46:57PM +0700, Victor Sudakov wrote: > greenh wrote: > > Nginx закроет соединение, а php код будет работать до того момента, пока не > > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - > > то безконечно. > > Вот это плохо. > > А почему так? Ведь обычная программа (не демон), как правило, > завершается или хотя бы останавливается, если ей каналы ввода-вывода > закрыли. да нет же. это твои влажные фантазии. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
13.04.2021 17:31, Victor Sudakov пишет:
> greenh wrote:
>> Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП
>> процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы
>> запускаете что то очень тяжелое по хттп запросу - это явно ошибка
>> архитектуры.
>> Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь
>> соврать, но момент, когда можно будет точно сказать, что браузер закрыт
>> наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем
>> случае существенно позже, чем скрипт отработает и умрет
>
> В случае таймаута да, а если клиент штатно завершил TCP соединение,
> зачем тратить ресурсы на поддержание соединения от nginx к upstream?
>
> Хоть Wireshark в руки бери, но кто-то же из присутствующих знает теорию?
При закрытии TCP-сокета клиентской стороной на запись (или вообще)
операционная система клиента отправляет данные из очереди отправки,
если она не пуста, дожидается ACK от сервера и отправляет FIN.
Это IEEE Std 1003.1g-2000 ("POSIX.1g"), если верить man 2 shutdown.
Если FIN дошел, то попытка почитать данные из сокета при помощи recv*
должна возвращать ECONNRESET, а мониторинг сокета при помощи poll вернуть
POLLHUP,
kqueue возвращает EV_EOF и т.п.
Будет ли сторона php/fastcgi мониторить свои сокеты - вопрос к ним.
Если приложение в конвейере пытается писать или читать в уже закрытый pipe это
одно,
а вот если оно не пытается - никто не будет его убивать.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
вт, 13 апр. 2021 г. в 13:32, Victor Sudakov : > greenh wrote: > > Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП > > процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы > > запускаете что то очень тяжелое по хттп запросу - это явно ошибка > > архитектуры. > > Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь > > соврать, но момент, когда можно будет точно сказать, что браузер закрыт > > наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем > > случае существенно позже, чем скрипт отработает и умрет > > В случае таймаута да, а если клиент штатно завершил TCP соединение, > зачем тратить ресурсы на поддержание соединения от nginx к upstream? > > Хоть Wireshark в руки бери, но кто-то же из присутствующих знает теорию? > Я никогда в логах ФПМ не видел информации о том, что соединение закрыто со стороне nginx. Или не помню ( > > -- > 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
вт, 13 апр. 2021 г. в 13:28, Victor Sudakov : > greenh wrote: > > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, > его > > процесс останется запущен, сокет, который он слушает останется активным и > > процессы внутри его продолжат работу. > > Почему бы сокет останется активным, если nginx закрыл соединение к > апстриму? Или nginx не закрывает соединение к апстриму, когда "браузер > сдох"? > > Сокет останется открытым, а не соединение > Вообще nginx на каждый запрос открывает новое соединение (TCP или Unix > socket) с апстримом, или всё время держит одно соединение с апстримом и > все запросы к php-fpm через это одно соединение идут? > > > Уточнить причину такого поведения, я > > думаю, стоит у разработчиков php-fpm. > > Сперва бы ответить на вопрос выше, а это вопрос по nginx. Судя по > наличию параметра max_conns у upstream, всё же имеют место быть > одновременно много соединений к одному апстриму. > > -- > 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
greenh wrote: > Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП > процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы > запускаете что то очень тяжелое по хттп запросу - это явно ошибка > архитектуры. > Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь > соврать, но момент, когда можно будет точно сказать, что браузер закрыт > наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем > случае существенно позже, чем скрипт отработает и умрет В случае таймаута да, а если клиент штатно завершил TCP соединение, зачем тратить ресурсы на поддержание соединения от nginx к upstream? Хоть Wireshark в руки бери, но кто-то же из присутствующих знает теорию? -- 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)
greenh wrote: > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, его > процесс останется запущен, сокет, который он слушает останется активным и > процессы внутри его продолжат работу. Почему бы сокет останется активным, если nginx закрыл соединение к апстриму? Или nginx не закрывает соединение к апстриму, когда "браузер сдох"? Вообще nginx на каждый запрос открывает новое соединение (TCP или Unix socket) с апстримом, или всё время держит одно соединение с апстримом и все запросы к php-fpm через это одно соединение идут? > Уточнить причину такого поведения, я > думаю, стоит у разработчиков php-fpm. Сперва бы ответить на вопрос выше, а это вопрос по nginx. Судя по наличию параметра max_conns у upstream, всё же имеют место быть одновременно много соединений к одному апстриму. -- 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)
Мне кажется, что так оно работать не будет. Да собственно и зачем? ПХП процесс в среднем случае легкий и быстрый. Отработает и умрет. Если Вы запускаете что то очень тяжелое по хттп запросу - это явно ошибка архитектуры. Да и определить закрытие браузера не всегда возможно. Опять таки, боюсь соврать, но момент, когда можно будет точно сказать, что браузер закрыт наступит довольно не скоро (я имею в виду TCP таймауты и пр), и в среднем случае существенно позже, чем скрипт отработает и умрет вт, 13 апр. 2021 г. в 13:18, Victor Sudakov : > greenh wrote: > > А какое поведение вы хотите получить? > > Закрыли браузер - обслуживавший этот сеанс процесс PHP безусловно > завершился, что бы ни делал в этот момент. > > -- > 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
greenh wrote: > А какое поведение вы хотите получить? Закрыли браузер - обслуживавший этот сеанс процесс PHP безусловно завершился, что бы ни делал в этот момент. -- 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)
А какое поведение вы хотите получить? вт, 13 апр. 2021 г., 13:00 greenh : > Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) > просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, его > процесс останется запущен, сокет, который он слушает останется активным и > процессы внутри его продолжат работу. Уточнить причину такого поведения, я > думаю, стоит у разработчиков php-fpm. > > вт, 13 апр. 2021 г. в 10:52, Victor Sudakov : > >> Aleksandr Sytar wrote: >> > >> > > Что должно >> > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? >> > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код >> продолжит >> > > работу? Или должен прерваться? >> > > >> > > Прошу прощения за сумбурное изложение, поправки и указания на неверное >> > > понимание логики работы с благодарностью принимаются. >> > > >> > > >> > > >> > Раз - https://habr.com/ru/post/179399/ >> > Двас - >> https://www.php.net/manual/ru/function.fastcgi-finish-request.php и >> > крути себе дальше в базе что надо. >> >> Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть >> обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс >> PHP завершился, что бы ни делал в этот момент. >> >> А в приведенных ссылках обратную задачу пытаются решить. >> >> Антиоффтопик. nginx-то что делает в момент закрытия соединения >> клиентским браузером: закрывает ли соответствущее соединение с fastcgi >> upstream-ом? >> >> -- >> 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 > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Боюсь ошибиться, но я думаю что он (когда узнает о том, что браузер сдох) просто перестанет ждать ответа на запрос от пхп но: пхп останется жить, его процесс останется запущен, сокет, который он слушает останется активным и процессы внутри его продолжат работу. Уточнить причину такого поведения, я думаю, стоит у разработчиков php-fpm. вт, 13 апр. 2021 г. в 10:52, Victor Sudakov : > Aleksandr Sytar wrote: > > > > > Что должно > > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код > продолжит > > > работу? Или должен прерваться? > > > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > > понимание логики работы с благодарностью принимаются. > > > > > > > > > > > Раз - https://habr.com/ru/post/179399/ > > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php > и > > крути себе дальше в базе что надо. > > Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть > обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс > PHP завершился, что бы ни делал в этот момент. > > А в приведенных ссылках обратную задачу пытаются решить. > > Антиоффтопик. nginx-то что делает в момент закрытия соединения > клиентским браузером: закрывает ли соответствущее соединение с fastcgi > upstream-ом? > > -- > 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Aleksandr Sytar wrote: > > > Что должно > > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > > работу? Или должен прерваться? > > > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > > понимание логики работы с благодарностью принимаются. > > > > > > > Раз - https://habr.com/ru/post/179399/ > Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и > крути себе дальше в базе что надо. Я наверное плохо сформулировал вопрос, но мне как раз интересно видеть обратное поведение. Закрыли браузер - обслуживавший этот сеанс процесс PHP завершился, что бы ни делал в этот момент. А в приведенных ссылках обратную задачу пытаются решить. Антиоффтопик. nginx-то что делает в момент закрытия соединения клиентским браузером: закрывает ли соответствущее соединение с fastcgi upstream-ом? -- 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)
greenh wrote: > Nginx закроет соединение, а php код будет работать до того момента, пока не > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - > то безконечно. Вот это плохо. А почему так? Ведь обычная программа (не демон), как правило, завершается или хотя бы останавливается, если ей каналы ввода-вывода закрыли. Чтобы этого не происходило, запускают через nohup, daemon и проч. -- 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)
вт, 13 апр. 2021 г. в 08:11, Victor Sudakov : > Что должно > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > работу? Или должен прерваться? > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > понимание логики работы с благодарностью принимаются. > > > Раз - https://habr.com/ru/post/179399/ Двас - https://www.php.net/manual/ru/function.fastcgi-finish-request.php и крути себе дальше в базе что надо. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тонкости работы FastCGI (phpfpm)
Nginx закроет соединение, а php код будет работать до того момента, пока не наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 - то безконечно. вт, 13 апр. 2021 г. в 08:11, Victor Sudakov : > Коллеги, > > Есть момент, который я не понимаю, как работает. У nginx есть upstream, > который представляет собой хост с php7.4-fpm. Допустим на PHP написали > код, который зацикливается, или спит 3 часа, или посылает SQL запрос на > 3 часа работы - короче, работать собирается долго или бесконечно. > > Вот пришел от пользователя HTTP запрос, nginx его передал php-fpm в > злополучный код, phpfpm child начал бесконечную работу... Что должно > произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? > nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит > работу? Или должен прерваться? > > Прошу прощения за сумбурное изложение, поправки и указания на неверное > понимание логики работы с благодарностью принимаются. > > -- > 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Тонкости работы FastCGI (phpfpm)
Коллеги, Есть момент, который я не понимаю, как работает. У nginx есть upstream, который представляет собой хост с php7.4-fpm. Допустим на PHP написали код, который зацикливается, или спит 3 часа, или посылает SQL запрос на 3 часа работы - короче, работать собирается долго или бесконечно. Вот пришел от пользователя HTTP запрос, nginx его передал php-fpm в злополучный код, phpfpm child начал бесконечную работу... Что должно произойти, когда пользователь отменил HTTP запрос, или браузер закрыл? nginx закроет соответствующее соединение с php-fpm ? А PHP-код продолжит работу? Или должен прерваться? Прошу прощения за сумбурное изложение, поправки и указания на неверное понимание логики работы с благодарностью принимаются. -- 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
