Re: Вопрос про ngx_http_upstream_module
Oleg A. Mamontov wrote: > > > >Когда серверу в блоке upstream ставишь параметр backup или down и > >делаешь nginx reload, существующие соединения к данному серверу сразу > >сбрасываются или им дают доработать? > > После nginx reload, будут запущены новые рабочие процессы, принимающие > новые соединения. Соединения, обслуживаемые старыми процессами будут > жить до закрытия или до наступления worker_shutdown_timeout. Спасибо большое. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Вопрос про ngx_http_upstream_module
Коллеги, Когда серверу в блоке upstream ставишь параметр backup или down и делаешь nginx reload, существующие соединения к данному серверу сразу сбрасываются или им дают доработать? Можно эксперимент поставить, но вдруг кто знает ответ или документировано (а я не нашел). Заранее спасибо за ответ. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
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)
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)
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)
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)
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)
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)
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)
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
Тонкости работы 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
Re: .htaccess
k...@kvtsoftware.com wrote: >Скорее всего написан, например RusOnyx использует такую штуку у себя на >хостинге, автоматически конвертирует htaccess в правила для nginx Но ведь это фактически транслятор конфига apache в конфиг nginx, потому что в htaccess могут быть почти любые директивы apache. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
.htaccess
Коллеги, Много развелось Web-приложений и сайтов, которые очень сильно полагаются на код в .htaccess. Смотришь - а там и RewriteRule, и "Header set...", и установка каких-то переменных, и MIME types переопределяются... Есть какая-то общая теория и рекомендации, как всё это хозяйство переносить под nginx, например под php-fpm ? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Konstantin Tokarev wrote: > >> > Спасибо, надо попробовать. Осталось понять, как заставить FastCGI > >> > Wrapper по команде из nginx вызывать не > >> > /usr/local/winsite/cgi-bin/query.exe?foo, а > >> > "/usr/local/bin/wine /usr/local/winsite/cgi-bin/query.exe?foo" > >> > >> Как я уже написал, шелл-скриптом, например > >> > >> #!/bin/sh > >> > >> exec wine /usr/local/winsite/cgi-bin/query.exe > > > > Предлагается каждый виндовый CGI-шник индивидуально таким образом > > обернуть? Хлопотно это полбеды, беда же в том, что в HTML-формах ссылка > > именно на "/cgi-bin/query.exe?foo", а не на обёртку. Переписывать > > полсайта? > > Зачем, всего лишь назвать обертку query.exe, а реальные бинарники сложить в > другом месте Наверное можно, хотя надеялся обойтись без перелопачивания сайта. Что ж, всем спасибо за идеи и предложения, уже есть какой-то багаж для экспериментов. Если кому интересно, ради чего затевалось - это САБ "Ирбис64", точнее Web-ИРБИС. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Gena Makhomed wrote: > > >>> Осталось понять, как заставить FastCGI > >>> Wrapper по команде из nginx вызывать не > >>> /usr/local/winsite/cgi-bin/query.exe?foo, а > >>> "/usr/local/bin/wine /usr/local/winsite/cgi-bin/query.exe?foo" > > enable support for Windows executables using wine: > echo ':DOSWin:M::MZ::/usr/local/bin/wine:' > register > https://www.kernel.org/doc/html/v5.0/admin-guide/binfmt-misc.html Это судя по описанию Linux only, не пойдет. Хотя фича интересная, может когда пригодится, спасибо. > > Только при чем здесь FastCGI ? В каталоге /cgi-bin/ лежат обычные CGI. Данная рассылка посвящена nginx, тут вроде нет "обычных CGI" без внешней запускалки. > Вместо апача лучше всего будет использовать mini_httpd для их запуска. > http://mailman.nginx.org/pipermail/nginx-ru/2009-November/030177.html А под Windows этот mini_httpd или аналог есть, и чтобы работал под wine? Вдруг из него получится запускалка. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Konstantin Tokarev wrote: > >Спасибо, надо попробовать. Осталось понять, как заставить FastCGI > >Wrapper по команде из nginx вызывать не > >/usr/local/winsite/cgi-bin/query.exe?foo, а > >"/usr/local/bin/wine /usr/local/winsite/cgi-bin/query.exe?foo" > >Как я уже написал, шелл-скриптом, например > >#!/bin/sh > >exec wine /usr/local/winsite/cgi-bin/query.exe Предлагается каждый виндовый CGI-шник индивидуально таким образом обернуть? Хлопотно это полбеды, беда же в том, что в HTML-формах ссылка именно на "/cgi-bin/query.exe?foo", а не на обёртку. Переписывать полсайта? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Konstantin Tokarev wrote: > >> > Тот же вопрос, что к Andrey Kopeyko. Имеется в виду "пускалку CGI" > >> > виндовую, или юниксовую, и в каком месте в этой схеме вступает wine? > >> > >> Юниксовая пускалка, шелл-скрипт с командой запуска wine в качестве > >> cgi-обработчика > > > > Нет у меня уверенности, что такая схема заработает, потому что для > > работы CGI-приложения надо ведь передать ему переменные среды из > > веб-сервера, а в случае POST - ещё и информацию из браузера на stdin > > приложения. И передать stdout приложения обратно в веб-сервер. > > > > Думаете, wine пропустит всё это через себя? stdin и environment туда, > > stdout обратно... > > Из man wine: > > wine makes the environment variables of the shell from which it is started > accessible > to the Windows/DOS processes started. So use the appropriate syntax for your > shell to > enter environment variables you need. > > С потоками stdin и stdout тоже не должно ничего плохого произойти Спасибо, надо попробовать. Осталось понять, как заставить FastCGI Wrapper по команде из nginx вызывать не /usr/local/winsite/cgi-bin/query.exe?foo, а "/usr/local/bin/wine /usr/local/winsite/cgi-bin/query.exe?foo" -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Konstantin Tokarev wrote: [dd] > > > > Тот же вопрос, что к Andrey Kopeyko. Имеется в виду "пускалку CGI" > > виндовую, или юниксовую, и в каком месте в этой схеме вступает wine? > > Юниксовая пускалка, шелл-скрипт с командой запуска wine в качестве > cgi-обработчика > Нет у меня уверенности, что такая схема заработает, потому что для работы CGI-приложения надо ведь передать ему переменные среды из веб-сервера, а в случае POST - ещё и информацию из браузера на stdin приложения. И передать stdout приложения обратно в веб-сервер. Думаете, wine пропустит всё это через себя? stdin и environment туда, stdout обратно... Думается мне, что без виндового апача или виндового же FastCGI wrapper (такое существует в природе?), запущенных из-под Wine, не обойтись. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Konstantin Tokarev wrote: > > > >> Если бы поставили задачу запустить под Linux/FreeBSD виндовое > >> приложение, реализованное как CGI-сценарий в виде .exe файла, как бы вы > >> подошли? > > > > Уточните - а сколько rps требуется получить? > > > >> Данный виндовый exe-шник работает как cgi из-под виндового Apache, и > >> вроде как нормально запускается из Wine. > > > > Если требуется rps < 1 - то прямая схема: > > > > nginx -> Apache -> CGI -> Wine -> exe > > > > не доставит вам сильных проблем. > > Можно вместо целого Апача использовать более легковесную пускалку CGI, > например fcgiwrap или какой-нибудь lighttpd Тот же вопрос, что к Andrey Kopeyko. Имеется в виду "пускалку CGI" виндовую, или юниксовую, и в каком месте в этой схеме вступает wine? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: виндовый cgi
Andrey Kopeyko wrote: > > > Если бы поставили задачу запустить под Linux/FreeBSD виндовое > > приложение, реализованное как CGI-сценарий в виде .exe файла, как бы вы > > подошли? > > Уточните - а сколько rps требуется получить? Для начала требуется просто запустить в лабораторных условиях. > > > Данный виндовый exe-шник работает как cgi из-под виндового Apache, и > > вроде как нормально запускается из Wine. > > Если требуется rps < 1 - то прямая схема: > >nginx -> Apache -> CGI -> Wine -> exe > > не доставит вам сильных проблем. Не совсем понятно, где в этой схеме водораздел между Unix и Windows. Имеется в виду виндовый Apache под wine, или... Уточните пожалуйста. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
виндовый cgi
Коллеги, Если бы поставили задачу запустить под Linux/FreeBSD виндовое приложение, реализованное как CGI-сценарий в виде .exe файла, как бы вы подошли? Данный виндовый exe-шник работает как cgi из-под виндового Apache, и вроде как нормально запускается из Wine. Может есть какой-нибудь FastCGI сервер, который работает под Wine, и к нему уже ходить из nginx? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Drupal
Victor Sudakov wrote: > Коллеги, > > Кто использует Drupal8+php-fpm,скажите пожалуйста, статья > https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/ ещё > актуальна или мир изменился? Видимо не совсем актуальна, потому что при попытке установки модулей и тем возникает ошибка: Возникла AJAX HTTP ошибка. Полученный код HTTP: 403 Следует отладочная информация. Путь: /core/authorize.php/core/authorize.php?batch=1=6=do_nojs=do Текст Состояния: Forbidden Текст Ответа: 403 Forbidden 403 Forbidden nginx/1.15.8 === Notice: Undefined index: log in update_authorize_install_batch_finished() (line 293 of core/modules/update/update.authorize.inc). Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 293 of core/modules/update/update.authorize.inc). Notice: Undefined index: log in update_authorize_install_batch_finished() (line 334 of core/modules/update/update.authorize.inc). Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 335 of core/modules/update/update.authorize.inc). Установка не удалась! См. журнал ниже для получения дополнительной информации. На сайтах типа https://drupal.stackexchange.com/questions/192151/cannot-install-any-theme предлагают дополнить конфиг строчкой rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1; прямо в секции server. Как-то это некрасиво, хоть и вроде решает проблему, и в любом случае IMHO должно быть отражено в странице на Вики. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Drupal
Коллеги, Кто использует Drupal8+php-fpm,скажите пожалуйста, статья https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/ ещё актуальна или мир изменился? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Чайниковский вопрос про locations
Коллеги,
Прошу простить чайниковский вопрос, не могу пока перестроить мозги после
apache. Допустим имеется конфигурация
server {
listen 80 default;
location / {
root /home/www;
index index.html;
}
location ~ \.php$ {
root /home/www;
fastcgi_pass unix:/tmp/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
includefastcgi_params;
}
Контент основного сайта лежит в /home/www, динамические страницы
передаются в php-fpm, всё работает.
Теперь ставится moodle в /usr/local/www/moodle/, как мне сказать
nginx-у, что moodle должен быть доступен по ссылке
http://mysite.example/moodle ? Надо видимо сделать
location /moodle {
alias /usr/local/www/moodle/;
}
или даже
location /moodle {
root /usr/local/www/;
}
а с php-контентом внутри Moodle как быть?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
Иван wrote: > Ну вообще я же не телепатически эту инфу получил. Всё достаточно понятно > написано в https://nginx.org/ru/docs/http/ngx_http_core_module.html#root : > > "Путь к файлу формируется путём простого добавления URI к значению > директивы |root|." Что касается отдачи статики, то понятно что понятно. А в fastcgi передаются две переменные, DOCUMENT_ROOT и SCRIPT_NAME, и пока я не осознал, что SCRIPT_NAME равен REQUEST_URI целиком (а не только его последней компоненте, как я ошибочно полагал), ничего и не работало. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
Victor Sudakov wrote: > > > 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: > > > "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or > > > SCRIPT_FILENAME) set and is the script executable?" while reading > > > response header from upstream, client: 10.10.10.3, server: , request: > > > "GET /cgi-bin/test HTTP/1.1", upstream: > > > "fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru" Не поленился изложить для памяти и Гугла: https://victor-sudakov.dreamwidth.org/463780.html -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
Константин Ткаченко wrote:
> > 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr:
> > "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or
> > SCRIPT_FILENAME) set and is the script executable?" while reading response
> > header from upstream, client: 10.10.10.3, server: , request: "GET
> > /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:",
> > host: "admin.sibptus.ru"
> Владельца для /usr/local/www/cgi-bin/test пробовали ставить в www?
> Понятно, что есть чтение, но меня смущает эта директива fcgiwrap_user="www"
Нет, права и владельцы тут ни при чём, дело в другом.
Путь к скрипту задаётся (передаётся в fcgiwrap) склеиванием двух
переменных: SCRIPT_NAME и DOCUMENT_ROOT, которые получаются из
$fastcgi_script_name и $document_root соответственно. По умолчанию
$fastcgi_script_name=$request_uri, то есть при моей конфигурации
> > location /cgi-bin/ {
> > root /usr/local/www/cgi-bin;
> > include /usr/local/etc/nginx/fastcgi_params;
> > fastcgi_pass unix:/tmp/fcgiwrap.socket;
> > }
путь к cgi-скрипту получался "/usr/local/www/cgi-bin/cgi-bin/test",
понятно что такого пути нет. Поэтому надо было или урезать root до
"/usr/local/www", или задать свой $fastcgi_split_path_info, который бы
переопределил $fastcgi_script_name, отрезав от "/cgi-bin/test" только
последнюю компоненту.
Спасибо Иван за верную наводку.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
fcgiwrap с ключом -f маленько прояснил ситуацию, имею теперь сообщение
об ошибке в логе nginx:
2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: "Cannot
get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and
is the script executable?" while reading response header from upstream, client:
10.10.10.3, server: , request: "GET /cgi-bin/test HTTP/1.1", upstream:
"fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru"
С учетом нижепоказанного, чего ещё недостаёт?
location /cgi-bin/ {
root /usr/local/www/cgi-bin;
include /usr/local/etc/nginx/fastcgi_params;
fastcgi_pass unix:/tmp/fcgiwrap.socket;
}
$ egrep 'DOCUMENT_ROOT|SCRIPT_NAME' /usr/local/etc/nginx/fastcgi_params
fastcgi_param SCRIPT_NAME$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $document_root;
$ ls -al /usr/local/www/cgi-bin
total 12
drwxr-xr-x 2 root wheel 512 23 янв. 00:58 .
drwxr-xr-x 4 root wheel 512 22 янв. 22:56 ..
-rwxr-xr-x 1 root wheel 313 23 янв. 00:58 test
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fcgiwrap не могу запустить
Victor Sudakov wrote: > > > Если сказать > su -m www -c 'telnet /tmp/fcgiwrap.socket' > то соединяется с fastcgi-сервером (я правда не знаю, какую команду там > сказать можно, но права доступа к сокету у www явно есть). FastCGI server сам по себе однако работает: # ~/bin/debug_cgi.sh + SCRIPT_FILENAME=/usr/local/www/cgi-bin/test + export SCRIPT_FILENAME + REQUEST_URI=/test + export REQUEST_URI + REQUEST_METHOD=GET + export REQUEST_METHOD + su -m www -c '/usr/local/bin/cgi-fcgi -bind -connect /tmp/fcgiwrap.socket' Content-type: text/plain This is a test script This is a test script This is a test script This is a test script This is a test script This is a test script This is a test script -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
fcgiwrap не могу запустить
Коллеги, снимите с ручника пожалуйста, что не так?
nginx (FreeBSD 11.2, nginx-1.14.1_1,2) при обращении к /cgi-bin/test
возвращает "403 Forbidden". Самое странное, что в error.log по этому
поводу ничего не пишется. В access.log есть совершенно неинформативное
2001:470:35:7af::2 - - [22/Jan/2019:23:37:46 +0700] "GET /cgi-bin/test
HTTP/1.1" 403 25 "-" "Mozilla/5.0 (X11; FreeBSD amd64; rv:64.0) Gecko/20100101
Firefox/64.0"
Чего ему не хватает? И как хотя бы включить ошибки в error.log?
nginx.conf:
location /cgi-bin/ {
root /usr/local/www/cgi-bin;
include /usr/local/etc/nginx/fastcgi_params;
fastcgi_pass unix:/tmp/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
# ls -al /tmp/fcgiwrap.socket
srw--- 1 www wheel 0 22 янв. 23:33 /tmp/fcgiwrap.socket
rc.conf.local:
fcgiwrap_enable="YES"
fcgiwrap_socket_owner="www"
fcgiwrap_user="www"
fcgiwrap_socket="unix:/tmp/fcgiwrap.socket"
fcgiwrap_socket_mode="0600"
# ls -al /usr/local/www/cgi-bin
total 12
drwxr-xr-x 2 root wheel 512 22 янв. 22:58 .
drwxr-xr-x 4 root wheel 512 22 янв. 22:56 ..
-rwxr-xr-x 1 root wheel 103 22 янв. 22:58 test
# ps axwwu | grep cgi
www 85035 0,0 0,1 6388 1808 - Is 00:11 0:00,00 daemon:
/usr/local/sbin/fcgiwrap[85037] (daemon)
www 85037 0,0 0,1 6356 1832 - I00:11 0:00,00
/usr/local/sbin/fcgiwrap -s unix:/tmp/fcgiwrap.socket
Если сказать
su -m www -c 'telnet /tmp/fcgiwrap.socket'
то соединяется с fastcgi-сервером (я правда не знаю, какую команду там
сказать можно, но права доступа к сокету у www явно есть).
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
несуществующие .php файлы
Коллеги,
В нижеприведенной конфигурации как правильно сделать, чтобы при
обращении к несуществующим файлам .php выводилось не сообщение No
input file specified от php-fpm, а тоже бы происходило
перенаправление на index.php ?
Вообще в идеале хотелось бы сделать так, чтобы главный файл
index.php получал себе все запросы, кроме запросов к статическому контенту.
Может надо вообще избавиться от rewrite и ставить fastcgi_pass сразу в
location /?
Заранее спасибо за подсказку.
server {
location / {
rewrite ^(.*)$ /index.php?$1 ;
root /home/web/public ;
index index.php index.html index.htm;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
root /home/web/public ;
fastcgi_pass unix:/var/run/php-fpm.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
/home/web/public$fastcgi_script_name;
includefastcgi_params;
}
# static content
location ~* ^.+\.(js|ico|gif|jpg|png|swf|flv)$ {
root /home/web/public ;
expires 3d;
}
}
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx as TCP proxy
Коллеги,
Пытаюсь использовать nginx-devel-1.3.14 (из портов FreeBSD) как tcp load
balancer. Почему-то тест конфига не проходит с сообщением:
Performing sanity check on nginx configuration:
nginx: [warn] upstream test may not have port 80 in
/usr/local/etc/nginx/nginx.conf:34
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
Что я делаю не так? Заранее спасибо. Полный конфиг приведён ниже.
worker_processes 1;
events {
worker_connections 1024;
}
tcp {
upstream test {
# simple round-robin
server localhost:783;
server murka:783;
check interval=3000 rise=2 fall=5 timeout=1000;
}
server {
listen 7783;
proxy_pass test ;
}
}
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
