Re: nginx: worker process`ы называются nginx: master process
Hello! On Fri, Apr 16, 2021 at 08:45:15PM +0300, Gena Makhomed wrote: > On 16.04.2021 18:42, Maxim Dounin wrote: > > >> После перезапуска сервера htop показывает: > >> > >> └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> └─ nginx: worker process > >> > >> После ручного systemctl restart nginx все стало нормально: > >> > >> └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> └─ nginx: worker process > >> > >> Это какая-то ошибка в коде nginx, > >> что переименование процессов не всегда срабатывает? > > > Скорее процессы повисли где-то на запуске. Я такое наблюдал > > при прикрученном на серверах LDAP'е для пользователей/групп, > > который не работал, и соответственно запуск рабочих процессов > > вис где-то в районе setgid() / initgroups() / setuid(). > > Там используются бинарные сборки с сайта nginx.org, версия > 1.19.10 без сторонних и стандартных модулей. В конфигах nginx > тоже нет ничего нетривиального, используется несколько mediawiki > сайтов. Не важно, откуда сборки nginx'а и что в конфигах, важно - что в настройках системы. Ну то есть для того, чтобы завесить nginx при смене пользователя - вполне хватает настроенного в системе LDAP'а. > Если такая ситуация повторится в будущем - что мне следует > сделать, для того чтобы найти причину этого глюка с > непереименованием процессов? Смотреть дебаггером стек процессов, там будет всё понятно. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: worker process`ы называются nginx: master process
Hello! On Fri, Apr 16, 2021 at 08:45:15PM +0300, Gena Makhomed wrote: > On 16.04.2021 18:42, Maxim Dounin wrote: > > >> После перезапуска сервера htop показывает: > >> > >> └─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> └─ nginx: worker process > >> > >> После ручного systemctl restart nginx все стало нормально: > >> > >> └─ nginx: master process /usr/sbin/nginx -c > >> /etc/nginx/nginx.conf > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> ├─ nginx: worker process > >> └─ nginx: worker process > >> > >> Это какая-то ошибка в коде nginx, > >> что переименование процессов не всегда срабатывает? > > > Скорее процессы повисли где-то на запуске. Я такое наблюдал > > при прикрученном на серверах LDAP'е для пользователей/групп, > > который не работал, и соответственно запуск рабочих процессов > > вис где-то в районе setgid() / initgroups() / setuid(). > > Там используются бинарные сборки с сайта nginx.org, версия > 1.19.10 без сторонних и стандартных модулей. В конфигах nginx > тоже нет ничего нетривиального, используется несколько mediawiki > сайтов. Если такая ситуация повторится в будущем - что мне > следует сделать, для того чтобы найти причину этого глюка с > непереименованием процессов? > -- Best regards, > Gena > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: worker process`ы называются nginx: master process
On 16.04.2021 18:42, Maxim Dounin wrote: После перезапуска сервера htop показывает: └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf └─ nginx: worker process После ручного systemctl restart nginx все стало нормально: └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: worker process ├─ nginx: worker process ├─ nginx: worker process └─ nginx: worker process Это какая-то ошибка в коде nginx, что переименование процессов не всегда срабатывает? Скорее процессы повисли где-то на запуске. Я такое наблюдал при прикрученном на серверах LDAP'е для пользователей/групп, который не работал, и соответственно запуск рабочих процессов вис где-то в районе setgid() / initgroups() / setuid(). Там используются бинарные сборки с сайта nginx.org, версия 1.19.10 без сторонних и стандартных модулей. В конфигах nginx тоже нет ничего нетривиального, используется несколько mediawiki сайтов. Если такая ситуация повторится в будущем - что мне следует сделать, для того чтобы найти причину этого глюка с непереименованием процессов? -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: worker process`ы называются nginx: master process
Hello! On Fri, Apr 16, 2021 at 09:52:54AM +0300, Gena Makhomed wrote: > Здравствуйте, > All! > > После перезапуска сервера htop показывает: > > └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > └─ nginx: worker process > > После ручного > systemctl restart nginx все стало > нормально: > > └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > ├─ nginx: worker process > ├─ nginx: worker process > ├─ nginx: worker process > └─ nginx: worker process > > Это какая-то ошибка в коде nginx, > что переименование процессов не всегда срабатывает? Скорее процессы повисли где-то на запуске. Я такое наблюдал при прикрученном на серверах LDAP'е для пользователей/групп, который не работал, и соответственно запуск рабочих процессов вис где-то в районе setgid() / initgroups() / setuid(). -- Maxim Dounin http://mdounin.ru/ ___ 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: Варнинги после перехода на PHP 8
Content-Length не обязателен. Можете не передавать его вовсе On Fri, Apr 16, 2021, 12:08 PM Trecolom wrote: > Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Отсюда и варнинг. > Скрипт делает все верно, и Nginx отвечает верно. Но как убрать это > предупреждение? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291263,291278#msg-291278 > > ___ > 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: Варнинги после перехода на PHP 8
> Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Скрипт делает все верно почему верно? в RFC 2616 написано, что: 14.13 Content-Length The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. https://tools.ietf.org/html/rfc2616#page-119 если Вы объявляете, что "Content-Length: 0" , то никакого тела в ответе быть не должно. Если тело есть, то в "Content-Length: ХХ" нужно указать его размер. Также допускается опустить этот заголовок, если конкретный размер тела неизвестен на момент начала передачи, насколько я понимаю. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Варнинги после перехода на PHP 8
On Fri, Apr 16, 2021 at 03:07:54AM -0400, Trecolom wrote: > Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком > "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не > нулевые данные. Отсюда и варнинг. > Скрипт делает все верно, Нет. При "Content-Length: 0" тело должно содержать ноль байт. То есть никаких данных быть не должно, скрипт работает неправильно. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Варнинги после перехода на PHP 8
Что я выяснил. Скрипт сайта, в ответ на запрос с заголовком "If-Modified-Since" отдает Nginx-су заголовок "Content-Length 0" и не нулевые данные. Отсюда и варнинг. Скрипт делает все верно, и Nginx отвечает верно. Но как убрать это предупреждение? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291263,291278#msg-291278 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx: worker process`ы называются nginx: master process
Здравствуйте, All! После перезапуска сервера htop показывает: └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf └─ nginx: worker process После ручного systemctl restart nginx все стало нормально: └─ nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ├─ nginx: worker process ├─ nginx: worker process ├─ nginx: worker process └─ nginx: worker process Это какая-то ошибка в коде nginx, что переименование процессов не всегда срабатывает? -- Best regards, Gena ___ 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
