From volayvaz на gmail.com Fri Nov 3 09:55:54 2017 From: volayvaz на gmail.com (Maksim Zavyalov) Date: Fri, 03 Nov 2017 09:55:54 +0000 Subject: =?UTF-8?B?0J7Qv9GG0LjRjyBtdWx0aV9hY2NlcHQ=?= Message-ID: Коллеги, а поясните, пожалуйса, как работает эта опция? Я правильно понимаю, что выключенная по-умолчанию, она не делает воркеров неспособными обработать более одного подключения? И каковы могут быть побочные эффекты от ее включения? Спасибо заранее! -- WBR, Max Zavyalov. Sent from my Nexus 5 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Fri Nov 3 14:50:31 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 03 Nov 2017 17:50:31 +0300 Subject: =?UTF-8?B?UmU6INCe0L/RhtC40Y8gbXVsdGlfYWNjZXB0?= In-Reply-To: References: Message-ID: <2128466.tgqaPHqvBz@vbart-laptop> On Friday, 3 November 2017 12:55:54 MSK Maksim Zavyalov wrote: > Коллеги, а поясните, пожалуйса, как работает эта опция? Я правильно > понимаю, что выключенная по-умолчанию, она не делает воркеров неспособными > обработать более одного подключения? И каковы могут быть побочные эффекты > от ее включения? > > Спасибо заранее! https://forum.nginx.org/read.php?21,267183,267526 -- Валентин Бартенев From msmolev на gmail.com Fri Nov 3 19:15:35 2017 From: msmolev на gmail.com (Max Smolev) Date: Fri, 3 Nov 2017 14:15:35 -0500 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0YDQviBtdWx0aV9hY2NlcHQg0L/RgNC4INGA0LDQsdC+?= =?UTF-8?B?0YLQtSDRgSBORlM=?= Message-ID: Добрый вечер! Нужен совет -- стоит-ли использовать multi_accept когда файлы (статические) сервятся с NFS? Время ответа прыгает довольно сильно и, соответственно, я пытаюсь результаты кешировать и, если есть уже закешированный контент, то сначала отдать а уже потом проверять (а если на весь бедлам уходит больше 10 секунд то просто сдастся). Два сервера в одном конфиге, на разных портах. Внешний (куда ходит за контентом CDN) кэш-проксирует на внутренний (который непосредственно смотрит в NFS через root). Worker process выставлен в штук 200. Такое впечатление, что когда у NFS затык (сетевой? не совсем ясно) то текущий процесс соответственно ждёт пока всё вернётся. Стоит ли делать в таких случаях multi_accept? Или комбинацию из accept_mutex on и multi_accept off? (use epoll включено, живёт на AMI то бишь CentOS-вариант) Насколько я понимаю worker process обслуживают и то и другое одновременно, и если у NFS "затык" то такой момент может схавать все процессы? Для прокси выставлено proxy_cache_lock on; proxy_cache_revalidate on; proxy_cache_background_update on; proxy_connect_timeout 10s; proxy_read_timeout 10s; proxy_cache_lock_timeout 10s; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_http_version 1.1; -- Best wishes, Max ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Fri Nov 3 19:19:54 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Fri, 3 Nov 2017 12:19:54 -0700 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9GA0L4gbXVsdGlfYWNjZXB0INC/0YDQuCDRgNCw?= =?UTF-8?B?0LHQvtGC0LUg0YEgTkZT?= In-Reply-To: References: Message-ID: On 03/11/2017 12:15, Max Smolev wrote: > Добрый вечер! > > Нужен совет -- стоит-ли использовать multi_accept когда файлы > (статические) сервятся с NFS? [...] Если nfs залипает, то никакой multi_accept не поможет. Не надо трогать ни multi_accept, ни accept_mutex. -- Maxim Konovalov "I'm not a software developer, but it doesn't seem as rocket science" From msmolev на gmail.com Fri Nov 3 19:24:53 2017 From: msmolev на gmail.com (Max Smolev) Date: Fri, 3 Nov 2017 14:24:53 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9GA0L4gbXVsdGlfYWNjZXB0INC/0YDQuCDRgNCw?= =?UTF-8?B?0LHQvtGC0LUg0YEgTkZT?= In-Reply-To: References: Message-ID: Понял, спасибо. 2017-11-03 14:19 GMT-05:00 Maxim Konovalov : > On 03/11/2017 12:15, Max Smolev wrote: > > Добрый вечер! > > > > Нужен совет -- стоит-ли использовать multi_accept когда файлы > > (статические) сервятся с NFS? > [...] > > Если nfs залипает, то никакой multi_accept не поможет. > > Не надо трогать ни multi_accept, ни accept_mutex. > > -- > Maxim Konovalov > > "I'm not a software developer, but it doesn't seem as rocket > science" > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best wishes, Max ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From volayvaz на gmail.com Sat Nov 4 11:43:02 2017 From: volayvaz на gmail.com (Maksim Zavyalov) Date: Sat, 04 Nov 2017 11:43:02 +0000 Subject: =?UTF-8?B?UmU6INCe0L/RhtC40Y8gbXVsdGlfYWNjZXB0?= In-Reply-To: <2128466.tgqaPHqvBz@vbart-laptop> References: <2128466.tgqaPHqvBz@vbart-laptop> Message-ID: Спасибо! Понятно! пт, 3 нояб. 2017 г. в 17:50, Валентин Бартенев : > On Friday, 3 November 2017 12:55:54 MSK Maksim Zavyalov wrote: > > Коллеги, а поясните, пожалуйса, как работает эта опция? Я правильно > > понимаю, что выключенная по-умолчанию, она не делает воркеров > неспособными > > обработать более одного подключения? И каковы могут быть побочные эффекты > > от ее включения? > > > > Спасибо заранее! > > https://forum.nginx.org/read.php?21,267183,267526 > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Max Zavyalov. Sent from my Nexus 5 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Nov 5 01:18:13 2017 From: nginx-forum на forum.nginx.org (Scumtron) Date: Sat, 04 Nov 2017 21:18:13 -0400 Subject: =?UTF-8?B?UmVnZXhwINC00LvQuNC90L3QvtC5INGB0YLRgNC+0LrQuCDQsiBNYXA=?= Message-ID: <4938dc2ecbd8a03b60a640c339cedd8a.NginxMailingListRussian@forum.nginx.org> Здравствуйте, Определяю мобильного посетителя с помощью Map, заметил, что одна длинная строка гораздо сильнее нагружает Nginx, чем разбитая на части. Пробовал увеличить буфер map_hash_max_size до 4096, но разницы не заметил. Получается, что на многоядерном сервере (в моем случае 8 ядер), эффективней разбивать длинные строки на более мелкие части или все-таки необходимо увеличить какой-то буфер? map $http_user_agent $ua_device { default 'desktop'; ~*SM-N|Tapatalk|PDA|PPC|SAGEM|mmp|pocket|psp|symbian|Smartphone|smartfon|treo|up.browser|up.link|vodafone|wap|nokia|Series40|Series60|S60|SonyEricsson|N900|MAUI.*WAP.*Browser|LG-P500|iPhone.*Mobile|iPod|iTunes|BlackBerry|\bBB10\b|rim[0-9]+|HTC|HTC.*(Sensation|Evo|Vision|Explorer|6800|8100|8900|A7272|S510e|C110e|Legend|Desire|T8282)|APX515CKT|Qtek9090|APA9292KT|HD_mini|Sensation.*Z710e|PG86100|Z715e|Desire.*(A8181|HD)|ADR6200|ADR6425|001HT|Inspire\ 4G|Android.*\bEVO\b|Nexus\ One|Nexus\ S|Galaxy.*Nexus|Android.*Nexus.*Mobile|Dell.*Streak|Dell.*Aero|Dell.*Venue|DELL.*Venue\ Pro|Dell\ Flash|Dell\ Smoke|Dell\ Mini\ 3iX|XCD28|XCD35|\b001DL\b|\b101DL\b|\bGS01\b|sony|SonyEricsson|SonyEricssonLT15iv|LT18i|E10i|Asus.*Galaxy|PalmSource|Palm|Vertu|Vertu.*Ltd|Vertu.*Ascent|Vertu.*Ayxta|Vertu.*Constellation(F|Quest)?|Vertu.*Monika|Vertu.*Signature|IQ230|IQ444|IQ450|IQ440|IQ442|IQ441|IQ245|IQ256|IQ236|IQ255|IQ235|IQ245|IQ275|IQ240|IQ285|IQ280|IQ270|IQ260|IQ250|\b(SP-80|XT-930|SX-340|XT-930|SX-310|SP-360|SP60|SPT-800|SP-120|SPT-800|SP-140|SPX-5|SPX-8|SP-100|SPX-8|SPX-12)\b|PANTECH|IM-A|VEGA\ PTL21|PT003|P8010|ADR910L|P6030|P6020|P9070|P4100|P9060|P5000|CDM8992|TXT8045|ADR8995|IS11PT|P2030|P6010|P8000|PT002|IS06|CDM8999|P9050|PT001|TXT8040|P2020|P9020|P2000|P7040|P7000|C790|Samsung|BGT-S5230|GT-B2100|GT-B2700|GT-B2710|GT-B3210|GT-B3310|GT-B3410|GT-B3730|GT-B3740|GT-B5510|GT-B5512|GT-B5722|GT-B6520|GT-B7300|GT-B7320|GT-B7330|GT-B7350|GT-B7510|GT-B7722|GT-B7800|GT-C3|GT-C5010|GT-C5212|GT-C6620|GT-C6625|GT-C6712|GT-E|GT-I|GT-M3510|GT-M5650|GT-M7500|GT-M7600|GT-M7603|GT-M8800|GT-M8910|GT-N7000|GT-P6810|GT-P7100|GT-S|GT-S8530|GT-S8600|SCH-A310|SCH-A530|SCH-A570|SCH-A610|SCH-A630|SCH-A650|SCH-A790|SCH-A795|SCH-A850|SCH-A870|SCH-A890|SCH-A930|SCH-A950|SCH-A970|SCH-A990|SCH-I100|SCH-I110|SCH-I400|SCH-I405|SCH-I500|SCH-I510|SCH-I515|SCH-I600|SCH-I730|SCH-I760|SCH-I770|SCH-I830|SCH-I910|SCH-I920|SCH-LC11|SCH-N150|SCH-N300|SCH-R100|SCH-R300|SCH-R351|SCH-R4|SCH-T300|SCH-U|SCS-26UC|SGH-A|SGH-B|SGH-C|SGH-D307|SGH-D|SGH-D807|SGH-D980|SGH-E105|SGH-E200|SGH-E315|SGH-E316|SGH-E317|SGH-E335|SGH-E590|SGH-E635|SGH-E715|SGH-E890|SGH-F300|SGH-F480|SGH-I|SGH-J150|SGH-J200|SGH-L170|SGH-L700|SGH-M110|SGH-M150|SGH-M200|SGH-N|SGH-N7|SGH-P|SGH-Q105|SGH-R210|SGH-R220|SGH-R225|SGH-S105|SGH-S307|SGH-T|SGH-U|SGH-V|SGH-X|SGH-Z130|SGH-Z150|SGH-Z170|SGH-ZX10|SGH-ZX20|SHW-M110|SPH-A|SPH-D600|SPH-D700|SPH-D710|SPH-D720|SPH-I300|SPH-I325|SPH-I330|SPH-I350|SPH-I500|SPH-I600|SPH-I700|SPH-L700|SPH-M|SPH-N100|SPH-N200|SPH-N240|SPH-N300|SPH-N400|SPH-Z400|SWC-E100|SCH-i909|GT-N7100|GT-N8010|Motorola|\bDroid\b.*Build|DROIDX|Android.*Xoom|HRI39|MOT-|A1260|A1680|A555|A853|A855|A953|A955|A956|Motorola.*ELECTRIFY|Motorola.*i1|i867|i940|MB200|MB300|MB501|MB502|MB508|MB511|MB520|MB525|MB526|MB611|MB612|MB632|MB810|MB855|MB860|MB861|MB865|MB870|ME501|ME502|ME511|ME525|ME600|ME632|ME722|ME811|ME860|ME863|ME865|MT620|MT710|MT716|MT720|MT810|MT870|MT917|Motorola.*TITANIUM|WX435|WX445|XT3|XT502|XT530|XT531|XT532|XT535|XT6|XT7|XT8|XT9/i 'mobile'; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277193,277193#msg-277193 From nginx-forum на forum.nginx.org Mon Nov 6 00:57:28 2017 From: nginx-forum на forum.nginx.org (node) Date: Sun, 05 Nov 2017 19:57:28 -0500 Subject: =?UTF-8?B?0JrQsNC6INC/0LXRgNC10LTQsNGC0Ywg0LIgaW1hZ2UgZmlsdGVyINC00YDRg9Cz?= =?UTF-8?B?0L7QuSDQv9GD0YLRjCDQtNC+INC60LDRgNGC0LjQvdC60Lg/?= Message-ID: <4c70eed2383ff577c36a10b9c9e09f2a.NginxMailingListRussian@forum.nginx.org> Подскажите можно ли как то передать в image_filter другой путь до картинки или что то другое придумать? У меня есть 2 копии картинок, одна оригинальная другая уменьшенная, мне нужно сделать так что если высота изображения меньше 350px брать ее из папки /thumb/ для последующей ее обработки в image_filter, а не из папки original. Все ради того чтобы создавать маленькие копии с копий, а не обрабатывать большое изображение ради маленькой копии. На бекенде я проверяю высоту и присваиваю картинке соответствующий route для nginx, если высота меньше 350px, то к ссылке на картинку я добавляю GET запрос (route=resizethumb) Пример url: /original/99/image.jpg?w=300&h=200&route=resizethumb И нужно чтобы по url выше бралась картинки из /thumb/99/ без изменения URL В конфиге сделал следующее location ~* \.(gif|jpg|png)$ { if ($arg_route = "resizethumb") { return 410; } error_page 410 = @img_resize; } location @img_resize { # Тут берутся картинки из папки /original/ по ссылке приведенной выше # но мне нужно взять картинку из папки /thumb/ и передать ее в image_filter image_filter resize - $arg_h; } Как можно это осуществить? Можно ли изменить место расположения файла до обработке через image_filter? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277195,277195#msg-277195 From sargaskn на gmail.com Wed Nov 8 12:45:03 2017 From: sargaskn на gmail.com (Sargas) Date: Wed, 8 Nov 2017 14:45:03 +0200 Subject: Kubernetes ingress In-Reply-To: References: Message-ID: Приветствую! Использую ingress https://github.com/nginxinc/kubernetes-ingress , возникла проблема с websocket'ами. После релоада nginx остаются висеть воркеры nginx 762 0.0 0.0 89284 11292 ? S Nov07 0:15 nginx: worker process is shutting down nginx 26321 0.0 0.0 88008 10196 ? S Nov07 0:18 nginx: worker process is shutting down Разработчики добавили в сервис с nodejs отправку websocket ping-фреймов для проверки работоспособности соединения, но воркеры всё равно могут висеть от нескольких часов до суток. Я добавил в конфиг worker_shutdown_timeout 1m; http://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout Я ожидал что через минуту все воркеры завершатся, но этого не происходит. Конфиг nginx.conf https://pastebin.com/zQxC4B1J Конфиг server {} https://pastebin.com/mj8egpXJ nginx version: nginx/1.13.3 built by gcc 6.3.0 20170516 (Debian 6.3.0-18) built with OpenSSL 1.1.0f 25 May 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.13.3/debian/debuild-base/nginx-1.13.3=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' Подскажите, пожалуйста, должны ли по истечению таймаута worker_shutdown_timeout все старые воркеры завершать свою работу? Если должны, то в какую сторону копать и что проверить ? 10 апреля 2017 г., 16:04 пользователь Michael Pleshakov написал: > Здравствуйте, Sargas > > Проект будет поддерживаться: будем улучшать текущие возможности и > исправлять найденные дефекты. Новые возможности -- расширения Ingress через > аннотации -- в основном, добавляются сообществом. Проект является открытым > и мы с радостью принимаем пулл реквесты. > > --Михаил > > 2017-04-09 0:29 GMT+01:00 Sargas : > >> Здравствуйте. >> >> Скажите, пожалуйста, а есть ли у вас какие-то планы по развитию >> https://github.com/nginxinc/kubernetes-ingress ? >> >> Для разработки начали использовать ваш, сейчас думаем что выбирать. Ваш >> или тот что делают в сообществе https://github.com/kubernetes/ingress >> >> _______________________________________________ >> 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 > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From marck на rinet.ru Wed Nov 8 17:26:24 2017 From: marck на rinet.ru (Dmitry Morozovsky) Date: Wed, 8 Nov 2017 20:26:24 +0300 (MSK) Subject: rate limiter and rewrite together Message-ID: Коллеги, что-то мы мальца сломали мозг и явно не видим очевидного. Есть ситуация, когда все транзитные HTTP запросы клиента перехватываются и отправляются в специальный nginx, котогрый показывает специальную страничку. Но -- хочется этот поток ограничить, ибо иначе nginx начинает жрать процессор как не в себя, потому что клиент-то тупой запросов шлёт гору. и -- не получается. текущий вариант был таков: http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; error_log /var/log/nginx-error.log notice; proxy_buffering off; log_format rdr '[$time_local] $remote_addr [$http_host$request_uri] $server_name $server_port [$rdr] $status $body_bytes_sent'; limit_req_log_level info; limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { listen 127.0.0.1:8001; server_name localhost; access_log /var/log/nginx-access.log rdr; limit_req zone=one nodelay; limit_req_status 444; return 302 http://rinet.ru/nomoney/redirect.html?; } } не лимитит. чего мы не замечаем и где тупим? ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck на FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck на rinet.ru *** ------------------------------------------------------------------------ From ru на nginx.com Wed Nov 8 19:59:08 2017 From: ru на nginx.com (Ruslan Ermilov) Date: Wed, 8 Nov 2017 22:59:08 +0300 Subject: rate limiter and rewrite together In-Reply-To: References: Message-ID: <20171108195908.GB2623@lo0.su> Привет, Дима! On Wed, Nov 08, 2017 at 08:26:24PM +0300, Dmitry Morozovsky wrote: > Коллеги, > > > что-то мы мальца сломали мозг и явно не видим очевидного. > > Есть ситуация, когда все транзитные HTTP запросы клиента перехватываются и > отправляются в специальный nginx, котогрый показывает специальную страничку. > > Но -- хочется этот поток ограничить, ибо иначе nginx начинает жрать > процессор как не в себя, потому что клиент-то тупой запросов шлёт гору. > > и -- не получается. > > текущий вариант был таков: > > > http { > include mime.types; > default_type application/octet-stream; > sendfile on; > keepalive_timeout 65; > error_log /var/log/nginx-error.log notice; > proxy_buffering off; > > log_format rdr '[$time_local] $remote_addr [$http_host$request_uri] $server_name $server_port [$rdr] $status $body_bytes_sent'; > limit_req_log_level info; > limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; > > server { > listen 127.0.0.1:8001; > server_name localhost; > access_log /var/log/nginx-access.log rdr; > limit_req zone=one nodelay; > limit_req_status 444; > return 302 http://rinet.ru/nomoney/redirect.html?; > } > } > > не лимитит. > > чего мы не замечаем и где тупим? ;) А не замечаете вы директивы return модуля rewrite, которая не даёт работать в т.ч. limit_req'у (обработка запроса попросту до нужной фазы не доходит). Как раз недавно обсуждали подобный юзкейс, ну и лайфхак какой-то такой будет: location / { limit_req zone=one nodelay; limit_req_status 444; try_files /nonexistent @redirect; } location @redirect { return 302 http://rinet.ru/nomoney/redirect.html?; } P.S. Знак вопроса в конце URI в return остался от rewrite'а, или так и задумано? From nginx-forum на forum.nginx.org Thu Nov 9 08:04:07 2017 From: nginx-forum на forum.nginx.org (m15255992020) Date: Thu, 09 Nov 2017 03:04:07 -0500 Subject: Nanjing Huiguang Lighting Co., Ltd Message-ID: <28712f6b911cdbfe33b8621813451614.NginxMailingListRussian@forum.nginx.org> Huiguang lighting is a company that specializes in the design, production and sales of lighting products. As a result, the company advocates energy conservation and environmental protection, economical and green lighting concept.We are committed to providing professional, dedicated and specialized lighting solutions for our customers. Founded in 2000, the company has more than 210 employees, covering a total area of 16,500 square meters. The company and products have passed the certification of ISO9001 quality system, EMC, CE, ROHS, IP68, CCC and CQC, and have more than 20 patents. Company has complete testing equipment for product safety testing, product environment adaptability test, light distribution test, life test, IP waterproof dustproof test, can provide customers with OEM, ODM services. Our mission is to provide professional lighting products and services to create value for society. Our vision is to be the best partner in the field of professional lighting in the world. http://www.hgledlight.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277218,277218#msg-277218 From nginx-forum на forum.nginx.org Thu Nov 9 10:40:49 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Thu, 09 Nov 2017 05:40:49 -0500 Subject: =?UTF-8?B?VXBzdHJlYW0gINC90LXQv9C+0L3Rj9GC0L3QviAg0L/QvtCy0LXQtNC10L3QuNC1?= Message-ID: <1d232dade922c5e8f650544c9244dacf.NginxMailingListRussian@forum.nginx.org> Приветсвую! Столкнулся со странной проблемой: # nginx -V nginx version: nginx/1.12.1 built with OpenSSL 1.0.2l 25 May 2017 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_addition_module --with-http_auth_request_module --add-module=/wrkdirs/usr/ports/www/nginx/work/ngx_http_geoip2_module-2.0 --with-http_geoip_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_realip_module --with-http_stub_status_module --add-module=/wrkdirs/usr/ports/www/nginx/work/ngx_devel_kit-0.3.0 --add-module=/wrkdirs/usr/ports/www/nginx/work/lua-nginx-module-0.10.8 --with-pcre --with-http_ssl_module server { listen 80; server_name test.example.com; error_log /var/log/nginx/test.error_log; access_log /var/log/nginx/test.access_log main; location / { proxy_pass http://test; proxy_next_upstream error timeout invalid_header non_idempotent http_500 http_503 http_502 http_504; } } server { listen 127.0.0.1:22001 default_server ; error_log /var/log/nginx/test1.error_log; return 500; } server { listen 127.0.0.1:22002 default_server ; error_log /var/log/nginx/test2.error_log; default_type text/html; return 200 "

TEST2

"; } upstream test { server 127.0.0.1:22001; server 127.0.0.1:22002 backup; } Теоретически, после первого обращения все последующие запросы в течении 10 секунд перенаправляются сразу на бэкап, и так оно и происходит на тестовом сервере: 192.168.1.1 - - [08/Nov/2017:18:47:44 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:44 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:44 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.001" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.001" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:51 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:47:55 +0300] "GET / HTTP/1.0" 200 392 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" Но на боевом сервере с теми же конфигами и версией софта картина почему-то меняется: 192.168.1.1 - - [08/Nov/2017:18:50:32 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:32 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:33 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:33 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:34 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:34 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:34 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:35 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:35 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:36 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:36 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:36 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:37 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:37 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:38 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:38 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:38 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000, 0.000" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:39 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.000" "0.000" "127.0.0.1:22002" "200" "nginx" 192.168.1.1 - - [08/Nov/2017:18:50:39 +0300] "GET / HTTP/1.1" 200 397 "-" "curl/7.56.1" "-" "192.168.1.1" "0.001" "0.000, 0.001" "127.0.0.1:22001, 127.0.0.1:22002" "500, 200" "nginx" Подскажите, почему может отличатся поведение на разных машинах, если софт и конфиги идентичны? Разница только в том, что один нагружен, другой нет, ну и в железе? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277219,277219#msg-277219 From gmm на csdoc.com Thu Nov 9 12:51:44 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 14:51:44 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf Message-ID: Здравствуйте, All! В чем смысл директивы ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf в файле /usr/lib/systemd/system/nginx.service ? У меня из-за этой фигни nginx не поднялся после того, как сервер перезапустился. В логах вот такая запись: Nov 09 13:26:30 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" Nov 09 13:26:51 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" Nov 09 13:27:11 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" Nov 09 13:27:31 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" Nov 09 13:27:40 example.com systemd[1]: nginx.service start-pre operation timed out. Terminating. Nov 09 13:27:40 example.com systemd[1]: Failed to start nginx - high performance web server. Nov 09 13:27:40 example.com systemd[1]: Unit nginx.service entered failed state. Nov 09 13:27:40 example.com systemd[1]: nginx.service failed. После того как вручную сделал systemctl restart nginx - все поднялось. Может быть имеет смысл убрать строчку ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf из файла /usr/lib/systemd/system/nginx.service ? Ведь никаких проблем эта строка ExecStartPre= не решает, а только создает новые. Или я ошибаюсь, и для чего-то эта строчка ExecStartPre= там нужна? Для чего? -- Best regards, Gena From medvedev.yp на gmail.com Thu Nov 9 12:55:07 2017 From: medvedev.yp на gmail.com (Iurii Medvedev) Date: Thu, 9 Nov 2017 15:55:07 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf это всего лишь тест конфигурации и он у вас провалился 9 ноября 2017 г., 15:51 пользователь Gena Makhomed написал: > Здравствуйте, All! > > В чем смысл директивы > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > в файле /usr/lib/systemd/system/nginx.service ? > > У меня из-за этой фигни nginx не поднялся после того, > как сервер перезапустился. В логах вот такая запись: > > Nov 09 13:26:30 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:26:51 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:11 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:31 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:40 example.com systemd[1]: nginx.service start-pre operation > timed out. Terminating. > Nov 09 13:27:40 example.com systemd[1]: Failed to start nginx - high > performance web server. > Nov 09 13:27:40 example.com systemd[1]: Unit nginx.service entered failed > state. > Nov 09 13:27:40 example.com systemd[1]: nginx.service failed. > > После того как вручную сделал systemctl restart nginx - все поднялось. > > Может быть имеет смысл убрать строчку > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > из файла /usr/lib/systemd/system/nginx.service ? > > Ведь никаких проблем эта строка ExecStartPre= не решает, > а только создает новые. > > Или я ошибаюсь, и для чего-то эта строчка ExecStartPre= там нужна? > > Для чего? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- With best regards Iurii Medvedev ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Nov 9 13:03:33 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 15:03:33 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: <52f833a0-2d12-4f8d-cb53-0fc7b423c994@csdoc.com> On 09.11.2017 14:55, Iurii Medvedev wrote: > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf это всего лишь > тест конфигурации Спасибо, я знаю что это такое. > и он у вас провалился Нет. С конфигурацией все нормально, после того как вручную сделал systemctl restart nginx - все поднялось. В конфиге ничего не правил. systemd отказался запускать юнит, потому что команда из строчки ExecStartPre= очень долго отрабатывала, в логе об этом же написано. -- Best regards, Gena From medvedev.yp на gmail.com Thu Nov 9 13:10:57 2017 From: medvedev.yp на gmail.com (Iurii Medvedev) Date: Thu, 9 Nov 2017 16:10:57 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <52f833a0-2d12-4f8d-cb53-0fc7b423c994@csdoc.com> References: <52f833a0-2d12-4f8d-cb53-0fc7b423c994@csdoc.com> Message-ID: Смысл это . строчки как раз и проверить конфигурацию перед стартом. https://www.nginx.com/resources/wiki/start/topics/examples/systemd/ И это правильно. 9 ноября 2017 г., 16:03 пользователь Gena Makhomed написал: > On 09.11.2017 14:55, Iurii Medvedev wrote: > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf это всего лишь >> тест конфигурации >> > > Спасибо, я знаю что это такое. > > и он у вас провалился >> > > Нет. С конфигурацией все нормально, после того как вручную сделал > systemctl restart nginx - все поднялось. > > В конфиге ничего не правил. > > systemd отказался запускать юнит, потому что команда > из строчки ExecStartPre= очень долго отрабатывала, > в логе об этом же написано. > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- With best regards Iurii Medvedev ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Nov 9 13:25:13 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 15:25:13 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: <52f833a0-2d12-4f8d-cb53-0fc7b423c994@csdoc.com> Message-ID: <693373f3-1adb-c362-ffb0-3fca68336b99@csdoc.com> On 09.11.2017 15:10, Iurii Medvedev wrote: > Смысл это . строчки как раз и проверить конфигурацию перед стартом. > https://www.nginx.com/resources/wiki/start/topics/examples/systemd/ > И это правильно. Во время запуска nginx и так проверяет конфигурацию. P.S. Вообще-то вопрос у меня был к разработчикам nginx, чтобы они поправили этот баг с невозможностью нормально запустить nginx при старте сервера. -- Best regards, Gena From kulmaks на gmail.com Thu Nov 9 13:29:54 2017 From: kulmaks на gmail.com (Maksim Kulik) Date: Thu, 9 Nov 2017 16:29:54 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <693373f3-1adb-c362-ffb0-3fca68336b99@csdoc.com> References: <52f833a0-2d12-4f8d-cb53-0fc7b423c994@csdoc.com> <693373f3-1adb-c362-ffb0-3fca68336b99@csdoc.com> Message-ID: Так это вам надо к разработчикам в багтрекер, а не в рассылку: либо пофиксят, либо объяснят почему фиксить не будут. https://trac.nginx.org/nginx/ 9 ноября 2017 г., 16:25 пользователь Gena Makhomed написал: > > > P.S. Вообще-то вопрос у меня был к разработчикам nginx, > чтобы они поправили этот баг с невозможностью нормально запустить nginx > при старте сервера. > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Nov 9 13:41:54 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 9 Nov 2017 18:41:54 +0500 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: в момент запуска nginx доступен ресолвер ? 9 ноября 2017 г., 17:51 пользователь Gena Makhomed написал: > Здравствуйте, All! > > В чем смысл директивы > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > в файле /usr/lib/systemd/system/nginx.service ? > > У меня из-за этой фигни nginx не поднялся после того, > как сервер перезапустился. В логах вот такая запись: > > Nov 09 13:26:30 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:26:51 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:11 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:31 example.com nginx[851]: nginx: [warn] "ssl_stapling" > ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" > in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:40 example.com systemd[1]: nginx.service start-pre operation > timed out. Terminating. > Nov 09 13:27:40 example.com systemd[1]: Failed to start nginx - high > performance web server. > Nov 09 13:27:40 example.com systemd[1]: Unit nginx.service entered failed > state. > Nov 09 13:27:40 example.com systemd[1]: nginx.service failed. > > После того как вручную сделал systemctl restart nginx - все поднялось. > > Может быть имеет смысл убрать строчку > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > из файла /usr/lib/systemd/system/nginx.service ? > > Ведь никаких проблем эта строка ExecStartPre= не решает, > а только создает новые. > > Или я ошибаюсь, и для чего-то эта строчка ExecStartPre= там нужна? > > Для чего? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Nov 9 13:42:34 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Nov 2017 16:42:34 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: <52f833a0-2d12-4f8d-cb53-0fc7b423c994@csdoc.com> <693373f3-1adb-c362-ffb0-3fca68336b99@csdoc.com> Message-ID: <20171109134234.GA26836@mdounin.ru> Hello! On Thu, Nov 09, 2017 at 04:29:54PM +0300, Maksim Kulik wrote: > Так это вам надо к разработчикам в багтрекер, а не в рассылку: либо > пофиксят, либо объяснят почему фиксить не будут. > https://trac.nginx.org/nginx/ Вы ошибаетесь, рассылка - куда более правильно место для подобных вопросов, чем багтрекер. Багтрекер нужен для того, чтобы отслеживать ошибки, в данном же случае речь явно идёт не об ошибке, а о вполне осмысленном действии - смыл которого, однако, не ясен. (И нет, это на самом деле вопрос не к разработчикам, а к maintainer'ам пакетов.) -- Maxim Dounin http://mdounin.ru/ From ano на bestmx.net Thu Nov 9 13:50:09 2017 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Thu, 9 Nov 2017 16:50:09 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: Илья Шипицин wrote: > в момент запуска nginx доступен ресолвер ? Вопрос-то не об этом. А о том, почему [warn] истолковывается как фатальная ошибка. From thresh на nginx.com Thu Nov 9 13:56:07 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 9 Nov 2017 16:56:07 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: On 09/11/2017 15:51, Gena Makhomed wrote: > Здравствуйте, All! > > В чем смысл директивы > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > в файле /usr/lib/systemd/system/nginx.service ? > > У меня из-за этой фигни nginx не поднялся после того, > как сервер перезапустился. В логах вот такая запись: > > Nov 09 13:26:30 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:26:51 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:11 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:31 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" > Nov 09 13:27:40 example.com systemd[1]: nginx.service start-pre operation timed out. Terminating. > Nov 09 13:27:40 example.com systemd[1]: Failed to start nginx - high performance web server. > Nov 09 13:27:40 example.com systemd[1]: Unit nginx.service entered failed state. > Nov 09 13:27:40 example.com systemd[1]: nginx.service failed. > > После того как вручную сделал systemctl restart nginx - все поднялось. Строчка в 13:26:30 - первая после запуска сервиса? Что выводит systemctl -a show nginx.service | grep -i timeout? -- Konstantin Pavlov www.nginx.com From nginx на mva.name Thu Nov 9 14:36:13 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 09 Nov 2017 21:36:13 +0700 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: <1866799.QUYqzfVYo5@note> В письме от четверг, 9 ноября 2017 г. 20:50:09 +07 пользователь Andrey Oktyabrskiy написал: > Илья Шипицин wrote: > > в момент запуска nginx доступен ресолвер ? > > Вопрос-то не об этом. А о том, почему [warn] истолковывается как > фатальная ошибка. он не истолковывается. Долистайте до конца лога. Фейл происходит из-за того что у ТС nginx слишком долго тестирует конфиг // тут я бы на его месте подумал о том, чтобы найти причину того что nginx так долго шуршит конфигом. Мне кажется, что проблема в том, что NgX по долгу ждёт таймаутов, связанных как раз с недоступностью резолвера. Так что нужно либо правильно настроить зависимости сервисов (чтобы резолвер (или сеть) стартовал(а) раньше NgX), либо уменьшить таймауты (что, вообще, имеет скорее негативный смысл) From gmm на csdoc.com Thu Nov 9 14:36:19 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 16:36:19 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> On 09.11.2017 15:41, Илья Шипицин wrote: >> в момент запуска nginx доступен ресолвер ? В конфиге у меня ресолвер вот так прописан: ssl_stapling on; resolver 8.8.8.8 8.8.4.4 ipv6=off; Да, вполне может быть и так, что не были доступны ресолверы, иначе я не знаю чем еще объяснить, почему проверка конфига $ nginx -T | grep "server {" | wc -l 21 $ nginx -T | grep "ssl_certificate_key" | wc -l 7 заняла более 90 секунд. Доступ ко всем бекендам прописан через статические IP внутренней сети, там ресолвер не используется: proxy_pass http://172.22.22.121/; Ресолвер в конфиге я включал только из-за директивы "ssl_stapling on". Но ведь ssl_stapling - это дополнительная функциональность, nginx же вполне может запуститься и работать вообще без ssl_stapling. Тем более, что это был даже не запуск nginx, а просто проверка конфига. Может быть во время проверки конфига на валидность имеет смысл вообще не ждать по 90 секунд неизвестно чего из-за директивы "ssl_stapling on" ? On 09.11.2017 15:50, Andrey Oktyabrskiy wrote: > Вопрос-то не об этом. А о том, почему [warn] истолковывается как > фатальная ошибка. Это не из-за warn, это из-за таймаута. У systemd дефолтовый таймаут на старт юнита - 90 секунд. Он был превышен, поэтому "Unit nginx.service entered failed state". -- Best regards, Gena From medvedev.yp на gmail.com Thu Nov 9 14:41:56 2017 From: medvedev.yp на gmail.com (Iurii Medvedev) Date: Thu, 9 Nov 2017 17:41:56 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> Message-ID: Проблем нет с исходящим трафиком? Я так понимаю у вас там летскрипт On Nov 9, 2017 17:36, "Gena Makhomed" wrote: On 09.11.2017 15:41, Илья Шипицин wrote: в момент запуска nginx доступен ресолвер ? >> > В конфиге у меня ресолвер вот так прописан: ssl_stapling on; resolver 8.8.8.8 8.8.4.4 ipv6=off; Да, вполне может быть и так, что не были доступны ресолверы, иначе я не знаю чем еще объяснить, почему проверка конфига $ nginx -T | grep "server {" | wc -l 21 $ nginx -T | grep "ssl_certificate_key" | wc -l 7 заняла более 90 секунд. Доступ ко всем бекендам прописан через статические IP внутренней сети, там ресолвер не используется: proxy_pass http://172.22.22.121/; Ресолвер в конфиге я включал только из-за директивы "ssl_stapling on". Но ведь ssl_stapling - это дополнительная функциональность, nginx же вполне может запуститься и работать вообще без ssl_stapling. Тем более, что это был даже не запуск nginx, а просто проверка конфига. Может быть во время проверки конфига на валидность имеет смысл вообще не ждать по 90 секунд неизвестно чего из-за директивы "ssl_stapling on" ? On 09.11.2017 15:50, Andrey Oktyabrskiy wrote: Вопрос-то не об этом. А о том, почему [warn] истолковывается как фатальная > ошибка. > Это не из-за warn, это из-за таймаута. У systemd дефолтовый таймаут на старт юнита - 90 секунд. Он был превышен, поэтому "Unit nginx.service entered failed state". -- Best regards, Gena _______________________________________________ nginx-ru mailing list nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Nov 9 14:56:38 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Nov 2017 17:56:38 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> References: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> Message-ID: <20171109145638.GE26836@mdounin.ru> Hello! On Thu, Nov 09, 2017 at 04:36:19PM +0200, Gena Makhomed wrote: > On 09.11.2017 15:41, Илья Шипицин wrote: > > >> в момент запуска nginx доступен ресолвер ? > > В конфиге у меня ресолвер вот так прописан: > > ssl_stapling on; > resolver 8.8.8.8 8.8.4.4 ipv6=off; > > Да, вполне может быть и так, что не были доступны ресолверы, > иначе я не знаю чем еще объяснить, почему проверка конфига > > $ nginx -T | grep "server {" | wc -l > 21 > > $ nginx -T | grep "ssl_certificate_key" | wc -l > 7 > > заняла более 90 секунд. Доступ ко всем бекендам прописан > через статические IP внутренней сети, там ресолвер не используется: > > proxy_pass http://172.22.22.121/; > > Ресолвер в конфиге я включал только из-за директивы "ssl_stapling on". > > Но ведь ssl_stapling - это дополнительная функциональность, > nginx же вполне может запуститься и работать вообще без ssl_stapling. > > Тем более, что это был даже не запуск nginx, а просто проверка конфига. > > Может быть во время проверки конфига на валидность имеет смысл > вообще не ждать по 90 секунд неизвестно чего из-за директивы > "ssl_stapling on" ? При использовании ssl_stapling nginx использует getaddrinfo() (то есть системный резолвер) для получения адресов на старте, а в процессе работы - обновляет адреса с помощью заданных в директиве resolver DNS-серверов. Так что сколько именно секунд ждать - это вопрос в первую очередь к настройкам системного резолвера. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Nov 9 14:57:53 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 16:57:53 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: Message-ID: <55338a5f-8564-a1f6-2aa6-d0697fec3bac@csdoc.com> On 09.11.2017 15:56, Konstantin Pavlov wrote: >> В чем смысл директивы >> >> ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf >> >> в файле /usr/lib/systemd/system/nginx.service ? В инит-скрипте CentOS 6 все сделано правильно, там конфиг тестируется только перед тем как выполнить рестар сервера: restart() { configtest_q || return 6 stop start } configtest_q() { $binary -t -q -c $config } и если тестирование конфигурации завершилось ошибкой - работающий nginx не останавливаается. В юнит-файле CentOS 7 эта строчка ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf выглядит совершенно лишней и не нужной, она только создает проблемы. Может быть имеет смысл вообще убрать строку ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf из юнит-файла? Хуже от этого ведь не станет, только лучше. Или я ошибаюсь и в этой строчке есть какой-смысл? Какой? >> У меня из-за этой фигни nginx не поднялся после того, >> как сервер перезапустился. В логах вот такая запись: >> >> Nov 09 13:26:30 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" >> Nov 09 13:26:51 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" >> Nov 09 13:27:11 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" >> Nov 09 13:27:31 example.com nginx[851]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt.org" in the certificate "/etc/letsencrypt/live/example.net/fullchain.pem" >> Nov 09 13:27:40 example.com systemd[1]: nginx.service start-pre operation timed out. Terminating. >> Nov 09 13:27:40 example.com systemd[1]: Failed to start nginx - high performance web server. >> Nov 09 13:27:40 example.com systemd[1]: Unit nginx.service entered failed state. >> Nov 09 13:27:40 example.com systemd[1]: nginx.service failed. >> >> После того как вручную сделал systemctl restart nginx - все поднялось. > > Строчка в 13:26:30 - первая после запуска сервиса? Из лога видно, что перед каждой такой строчкой [warn] nginx "думает" примерно 20 секунд. Таймаут получается ровно 90 секунд. > Что выводит systemctl -a show nginx.service | grep -i timeout? # systemctl -a show nginx.service | grep -i timeout TimeoutStartUSec=1min 30s TimeoutStopUSec=1min 30s JobTimeoutUSec=0 JobTimeoutAction=none JobTimeoutRebootArgument= -- Best regards, Gena From gmm на csdoc.com Thu Nov 9 15:11:46 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 17:11:46 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: References: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> Message-ID: <757a2c2a-4c09-d16e-0f30-bf6f4802359b@csdoc.com> On 09.11.2017 16:41, Iurii Medvedev wrote: > Проблем нет с исходящим трафиком? Я так понимаю у вас там летскрипт У меня там OVH, у них сегодня были проблемы с электричеством и сетью: https://pbs.twimg.com/media/DOMFo9CX0AAbEKv.jpg:large https://twitter.com/olesovhcom Не запустился nginx автоматически после того как электричество в датацентре появилось и сервер включился. Все остальные сервисы (sshd, postfix, openvpn) запустились нормально. PS Системный ресолвер был 213.186.33.99 из сети OVH, вполне возможно что он не был доступен в момент старта сервера. -- Best regards, Gena From gmm на csdoc.com Thu Nov 9 16:06:08 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 9 Nov 2017 18:06:08 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <20171109145638.GE26836@mdounin.ru> References: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> <20171109145638.GE26836@mdounin.ru> Message-ID: <7622426c-c839-668c-9fbf-9c3a894df37c@csdoc.com> On 09.11.2017 16:56, Maxim Dounin wrote: >> Ресолвер в конфиге я включал только из-за директивы "ssl_stapling on". >> >> Но ведь ssl_stapling - это дополнительная функциональность, >> nginx же вполне может запуститься и работать вообще без ssl_stapling. >> >> Тем более, что это был даже не запуск nginx, а просто проверка конфига. >> >> Может быть во время проверки конфига на валидность имеет смысл >> вообще не ждать по 90 секунд неизвестно чего из-за директивы >> "ssl_stapling on" ? > При использовании ssl_stapling nginx использует getaddrinfo() (то > есть системный резолвер) для получения адресов на старте, а в > процессе работы - обновляет адреса с помощью заданных в директиве > resolver DNS-серверов. > > Так что сколько именно секунд ждать - это вопрос в первую очередь > к настройкам системного резолвера. В функции ngx_ssl_stapling_responder() вызывается функция ngx_parse_url(), из нее вызывается ngx_parse_inet_url(), оттуда вызывается ngx_inet_resolve_host() которая вызывает getaddrinfo(). Не понятно другое, зачем при парсинге урлов из сертификатов надо ресолвить хосты? Мне еще ни разу не встречались удостоверяющие центры, которые в своих сертификатах прописывали невалидные хостнеймы для OCSP stapling. Значит и ресолвить их при старте сервиса смысла нет. Может быть имеет смысл к функции ngx_parse_url() добавить еще один параметр, который будет говорить, надо ли ресолвить хост во время парсинга урла? И тогда при использовании ssl_stapling можно будет не ресолвить хост, и nginx будет запускаться нормально, даже если есть временные проблемы с системным ресолвером? Сейчас же - из-за *временных* проблем с системным ресолвером полностью не стартует сервис nginx. Это как-то неправильно. Может быть лучше бы он стартовал и работал, даже если часть функциональности ssl_stapling будет временно не доступна из-за временно не ресолвящихся доменных имен? Коммерческие пользователи nginx+ наверное тоже подвержены этой проблеме. Хочется видеть nginx максимально надежным сервисом, без глюков. -- Best regards, Gena From mdounin на mdounin.ru Thu Nov 9 16:32:41 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Nov 2017 19:32:41 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <7622426c-c839-668c-9fbf-9c3a894df37c@csdoc.com> References: <07d5e28e-689a-7b89-119d-3bd591883e7b@csdoc.com> <20171109145638.GE26836@mdounin.ru> <7622426c-c839-668c-9fbf-9c3a894df37c@csdoc.com> Message-ID: <20171109163241.GG26836@mdounin.ru> Hello! On Thu, Nov 09, 2017 at 06:06:08PM +0200, Gena Makhomed wrote: > On 09.11.2017 16:56, Maxim Dounin wrote: > > >> Ресолвер в конфиге я включал только из-за директивы "ssl_stapling on". > >> > >> Но ведь ssl_stapling - это дополнительная функциональность, > >> nginx же вполне может запуститься и работать вообще без ssl_stapling. > >> > >> Тем более, что это был даже не запуск nginx, а просто проверка конфига. > >> > >> Может быть во время проверки конфига на валидность имеет смысл > >> вообще не ждать по 90 секунд неизвестно чего из-за директивы > >> "ssl_stapling on" ? > > > При использовании ssl_stapling nginx использует getaddrinfo() (то > > есть системный резолвер) для получения адресов на старте, а в > > процессе работы - обновляет адреса с помощью заданных в директиве > > resolver DNS-серверов. > > > > Так что сколько именно секунд ждать - это вопрос в первую очередь > > к настройкам системного резолвера. > > В функции ngx_ssl_stapling_responder() > вызывается функция ngx_parse_url(), из нее вызывается > ngx_parse_inet_url(), оттуда вызывается ngx_inet_resolve_host() > которая вызывает getaddrinfo(). > > Не понятно другое, > зачем при парсинге урлов из сертификатов надо ресолвить хосты? Полученные адреса используются для получения OCSP-ответов, если директива resolver не задана в конфигурации. [...] > И тогда при использовании ssl_stapling > можно будет не ресолвить хост, и nginx будет запускаться нормально, > даже если есть временные проблемы с системным ресолвером? > > Сейчас же - из-за *временных* проблем с системным ресолвером > полностью не стартует сервис nginx. Это как-то неправильно. Из приведённого лога очевидно, что каких-либо проблем со стороны nginx'а - нет. Старт не состоялся исключительно из-за того, что systemd решил, что nginx стартует слишком медленно. Это выглядит скорее как вопрос к настройкам системного резолвера и systemd, чем как вопрос к поведению nginx'а. [...] -- Maxim Dounin http://mdounin.ru/ From vbart на nginx.com Fri Nov 10 04:17:21 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Nov 2017 07:17:21 +0300 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtICDQvdC10L/QvtC90Y/RgtC90L4gINC/0L7QstC10LTQtdC9?= =?UTF-8?B?0LjQtQ==?= In-Reply-To: <1d232dade922c5e8f650544c9244dacf.NginxMailingListRussian@forum.nginx.org> References: <1d232dade922c5e8f650544c9244dacf.NginxMailingListRussian@forum.nginx.org> Message-ID: <2167688.9e0vuLmkpA@vbart-laptop> On Thursday, 9 November 2017 13:40:49 MSK BieZax wrote: [..] > > Теоретически, после первого обращения все последующие запросы в течении > 10 секунд перенаправляются сразу на бэкап, и так оно и происходит > на тестовом сервере: [..] В рамках одного рабочего процесса - да. > > Подскажите, почему может отличатся поведение на разных машинах, если > софт и конфиги идентичны? Разница только в том, что один нагружен, другой > нет, ну и в железе? > И сколько у вас рабочих процессов? -- Валентин Бартенев From vadim.lazovskiy на gmail.com Fri Nov 10 07:14:24 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Fri, 10 Nov 2017 10:14:24 +0300 Subject: nginx repos Ubuntu 17.10 artful Message-ID: Здравствуйте. Не могли бы вы приготовить пакеты для Ubuntu 17.10? Спасибо! -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Fri Nov 10 08:30:01 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Fri, 10 Nov 2017 03:30:01 -0500 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtICDQvdC10L/QvtC90Y/RgtC90L4gINC/0L7QstC10LTQtdC9?= =?UTF-8?B?0LjQtQ==?= In-Reply-To: <2167688.9e0vuLmkpA@vbart-laptop> References: <2167688.9e0vuLmkpA@vbart-laptop> Message-ID: <2f5b526b97c7d15254adedb3b0201186.NginxMailingListRussian@forum.nginx.org> worker_processes 24; на обеих машинах для чистоты эксперимента. Хотя физически на тестовой 2 ядра, а на боевой 32. Я так понимаю, что в документации об этом нюансе нигде не написано? Т.е. описание fail_timeout и max_fails актуально только в случае если клиент всегда попадает на один и тот же воркер, правильно? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277219,277260#msg-277260 From vbart на nginx.com Fri Nov 10 10:37:40 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Nov 2017 13:37:40 +0300 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtICDQvdC10L/QvtC90Y/RgtC90L4gINC/0L7QstC10LTQtdC9?= =?UTF-8?B?0LjQtQ==?= In-Reply-To: <2f5b526b97c7d15254adedb3b0201186.NginxMailingListRussian@forum.nginx.org> References: <2167688.9e0vuLmkpA@vbart-laptop> <2f5b526b97c7d15254adedb3b0201186.NginxMailingListRussian@forum.nginx.org> Message-ID: <2719721.DgGogWLJ35@vbart-workstation> On Friday 10 November 2017 03:30:01 BieZax wrote: > worker_processes 24; на обеих машинах для чистоты эксперимента. Хотя > физически на тестовой 2 ядра, а на боевой 32. > Я так понимаю, что в документации об этом нюансе нигде не написано? Т.е. > описание fail_timeout и max_fails актуально только в случае если > клиент всегда попадает на один и тот же воркер, правильно? [..] Зависит от того, настроили ли вы upstream с использованием разделяемой памяти или нет. http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#zone -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Nov 10 10:48:13 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Fri, 10 Nov 2017 05:48:13 -0500 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtICDQvdC10L/QvtC90Y/RgtC90L4gINC/0L7QstC10LTQtdC9?= =?UTF-8?B?0LjQtQ==?= In-Reply-To: <2719721.DgGogWLJ35@vbart-workstation> References: <2719721.DgGogWLJ35@vbart-workstation> Message-ID: Нет, я не являюсь пользователем платной подписки. Т.е. описание fail_timeout и max_fails актуально только в случае если клиент всегда попадает на один и тот же воркер или настроил upstream с использованием разделяемой памяти, верно? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277219,277264#msg-277264 From vbart на nginx.com Fri Nov 10 10:59:44 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Nov 2017 13:59:44 +0300 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtICDQvdC10L/QvtC90Y/RgtC90L4gINC/0L7QstC10LTQtdC9?= =?UTF-8?B?0LjQtQ==?= In-Reply-To: References: <2719721.DgGogWLJ35@vbart-workstation> Message-ID: <1809928.t83vvjR27v@vbart-workstation> On Friday 10 November 2017 05:48:13 BieZax wrote: > Нет, я не являюсь пользователем платной подписки. Т.е. описание > fail_timeout и max_fails актуально только в случае если клиент всегда > попадает на один и тот же воркер или настроил upstream с использованием > разделяемой памяти, верно? > [..] Описание директив актуально в любом случае. Но если информация об upstream-серверах хранится в локальной памяти процессов, то соответственно каждый процесс имеет свое независимое представление об их состоянии. Если вдруг сервер недоступен, то каждый процесс должен будет сам узнать об этом. И непонятно, причем тут платная подписка. Директива zone в бесплатной версии. -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Nov 10 11:03:34 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 10 Nov 2017 06:03:34 -0500 Subject: gzip filter failed to use preallocated memory In-Reply-To: <7c7b5f6d166e1e5cdb27108f57a07a37.NginxMailingListRussian@forum.nginx.org> References: <7c7b5f6d166e1e5cdb27108f57a07a37.NginxMailingListRussian@forum.nginx.org> Message-ID: <0bee6ad2c3589d555d1590cac8bd2668.NginxMailingListRussian@forum.nginx.org> Есть смысл мне писать в bug report, по этой проблеме, или шансы на исправление близки к нулю? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276955,277266#msg-277266 From nginx-forum на forum.nginx.org Fri Nov 10 11:07:28 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Fri, 10 Nov 2017 06:07:28 -0500 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtICDQvdC10L/QvtC90Y/RgtC90L4gINC/0L7QstC10LTQtdC9?= =?UTF-8?B?0LjQtQ==?= In-Reply-To: <1809928.t83vvjR27v@vbart-workstation> References: <1809928.t83vvjR27v@vbart-workstation> Message-ID: Прошу прощения про zone, неправильно понял документацию. Теперь все работает, как ожидалось. Спасибо за разъяснение! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277219,277269#msg-277269 From thresh на nginx.com Fri Nov 10 11:13:00 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Fri, 10 Nov 2017 14:13:00 +0300 Subject: nginx repos Ubuntu 17.10 artful In-Reply-To: References: Message-ID: <4c3a5b30-a6bc-0378-6118-2a0747f906bd@nginx.com> Добрый день, On 10/11/2017 10:14, Vadim Lazovskiy wrote: > Здравствуйте. > > Не могли бы вы приготовить пакеты для Ubuntu 17.10? > > Спасибо! Будет со следующим mainline релизом. -- Konstantin Pavlov www.nginx.com From mdounin на mdounin.ru Fri Nov 10 11:33:19 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 10 Nov 2017 14:33:19 +0300 Subject: gzip filter failed to use preallocated memory In-Reply-To: <0bee6ad2c3589d555d1590cac8bd2668.NginxMailingListRussian@forum.nginx.org> References: <7c7b5f6d166e1e5cdb27108f57a07a37.NginxMailingListRussian@forum.nginx.org> <0bee6ad2c3589d555d1590cac8bd2668.NginxMailingListRussian@forum.nginx.org> Message-ID: <20171110113319.GJ26836@mdounin.ru> Hello! On Fri, Nov 10, 2017 at 06:03:34AM -0500, S.A.N wrote: > Есть смысл мне писать в bug report, по этой проблеме, или шансы на > исправление близки к нулю? Есть смысл разобраться, что у вас используется вместо zlib, как это что-то детектировать и аллоцировать под него память, и прислать патч. -- Maxim Dounin http://mdounin.ru/ From sargaskn на gmail.com Fri Nov 10 13:17:43 2017 From: sargaskn на gmail.com (Sargas) Date: Fri, 10 Nov 2017 15:17:43 +0200 Subject: Kubernetes ingress In-Reply-To: References: Message-ID: по strace видно что процесс обслуживает соединения https://pastebin.com/N0Y4AANj И вообщем-то процессы завершаются через какое-то время. Но время не прогнозируемое. И в случае DEV окружения релоады nginx могут каждых 10 минут происходить. Хотелось бы понимать что еще покрутить можно. 8 ноября 2017 г., 14:45 пользователь Sargas написал: > Приветствую! > > Использую ingress https://github.com/nginxinc/kubernetes-ingress , > возникла проблема с websocket'ами. После релоада nginx остаются висеть > воркеры > nginx 762 0.0 0.0 89284 11292 ? S Nov07 0:15 nginx: > worker process is shutting down > nginx 26321 0.0 0.0 88008 10196 ? S Nov07 0:18 nginx: > worker process is shutting down > > Разработчики добавили в сервис с nodejs отправку websocket ping-фреймов > для проверки работоспособности соединения, но воркеры всё равно могут > висеть от нескольких часов до суток. > Я добавил в конфиг worker_shutdown_timeout 1m; > http://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout > Я ожидал что через минуту все воркеры завершатся, но этого не происходит. > > Конфиг nginx.conf https://pastebin.com/zQxC4B1J > Конфиг server {} https://pastebin.com/mj8egpXJ > > nginx version: nginx/1.13.3 > built by gcc 6.3.0 20170516 (Debian 6.3.0-18) > built with OpenSSL 1.1.0f 25 May 2017 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log > --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx > --group=nginx --with-compat --with-file-aio --with-threads > --with-http_addition_module --with-http_auth_request_module > --with-http_dav_module --with-http_flv_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_mp4_module > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_status_module > --with-http_sub_module --with-http_v2_module --with-mail > --with-mail_ssl_module --with-stream --with-stream_realip_module > --with-stream_ssl_module --with-stream_ssl_preread_module > --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/ > builder/debuild/nginx-1.13.3/debian/debuild-base/nginx-1.13.3=. > -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong > -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' > --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro > -Wl,-z,now -Wl,--as-needed -pie' > > > Подскажите, пожалуйста, должны ли по истечению таймаута > worker_shutdown_timeout все старые воркеры завершать свою работу? Если > должны, то в какую сторону копать и что проверить ? > > 10 апреля 2017 г., 16:04 пользователь Michael Pleshakov > написал: > > Здравствуйте, Sargas >> >> Проект будет поддерживаться: будем улучшать текущие возможности и >> исправлять найденные дефекты. Новые возможности -- расширения Ingress через >> аннотации -- в основном, добавляются сообществом. Проект является открытым >> и мы с радостью принимаем пулл реквесты. >> >> --Михаил >> >> 2017-04-09 0:29 GMT+01:00 Sargas : >> >>> Здравствуйте. >>> >>> Скажите, пожалуйста, а есть ли у вас какие-то планы по развитию >>> https://github.com/nginxinc/kubernetes-ingress ? >>> >>> Для разработки начали использовать ваш, сейчас думаем что выбирать. Ваш >>> или тот что делают в сообществе https://github.com/kubernetes/ingress >>> >>> _______________________________________________ >>> 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 >> > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Nov 10 14:35:02 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 10 Nov 2017 09:35:02 -0500 Subject: gzip filter failed to use preallocated memory In-Reply-To: <20171110113319.GJ26836@mdounin.ru> References: <20171110113319.GJ26836@mdounin.ru> Message-ID: > Есть смысл разобраться, что у вас используется вместо zlib, Из коробки в ОС установлена пропатченная Intel библиотека zlib https://software.intel.com/en-us/articles/how-to-use-zlib-with-intel-ipp-opertimization Вот что у нас выдает ldd ldd /usr/lib64/libz.so linux-vdso.so.1 (0x00007ffed8d7c000) libc.so.6 => /usr/lib64/haswell/libc.so.6 (0x00007fe455d53000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe455f8b000) > как это что-то детектировать и аллоцировать под него память, и > прислать патч. Мне сложно сказать как правильно детектировать эту библиотеку, и патч написать я тоже не смогу (я не Си разработчик) но могу тестировать. Intel, сделали хорошую работу, их gzip работает почти в 2 раза быстрей, не хочется возвращаться на стандартную zlib. Возможно будет достаточно если Nginx изменит уровень ошибки, сейчас уровень этой ошибки Alert, но это не правильно, потому что Nginx не падает и все работает, я думаю правильно выдавать Notice, тогда можно не логировать Notice уведомления и все будет норм? Спасабо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276955,277278#msg-277278 From thresh на nginx.com Fri Nov 10 14:37:54 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Fri, 10 Nov 2017 17:37:54 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <55338a5f-8564-a1f6-2aa6-d0697fec3bac@csdoc.com> References: <55338a5f-8564-a1f6-2aa6-d0697fec3bac@csdoc.com> Message-ID: <7440c153-18ca-f4ec-520c-173bd29244fa@nginx.com> On 09/11/2017 17:57, Gena Makhomed wrote: > On 09.11.2017 15:56, Konstantin Pavlov wrote: > >>> В чем смысл директивы >>> >>> ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf >>> >>> в файле /usr/lib/systemd/system/nginx.service ? > > В инит-скрипте CentOS 6 все сделано правильно, там конфиг тестируется > только перед тем как выполнить рестар сервера: > > restart() { >     configtest_q || return 6 >     stop >     start > } > > configtest_q() { >   $binary -t -q -c $config > } > > и если тестирование конфигурации завершилось ошибкой - > работающий nginx не останавливаается. Это, кстати, не работает в systemd-мире и не сказать, что бы это сильно заботило авторов: https://github.com/systemd/systemd/issues/2175 > В юнит-файле CentOS 7 эта строчка > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > выглядит совершенно лишней и не нужной, она только создает проблемы. > > Может быть имеет смысл вообще убрать строку > > ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf > > из юнит-файла? Хуже от этого ведь не станет, только лучше. > > Или я ошибаюсь и в этой строчке есть какой-смысл? Какой? Не ошибаетесь. -- Konstantin Pavlov www.nginx.com From gmm на csdoc.com Fri Nov 10 16:17:33 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 10 Nov 2017 18:17:33 +0200 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <7440c153-18ca-f4ec-520c-173bd29244fa@nginx.com> References: <55338a5f-8564-a1f6-2aa6-d0697fec3bac@csdoc.com> <7440c153-18ca-f4ec-520c-173bd29244fa@nginx.com> Message-ID: <02f54335-61a4-a333-33b0-3af822901431@csdoc.com> On 10.11.2017 16:37, Konstantin Pavlov wrote: >> В инит-скрипте CentOS 6 все сделано правильно, там конфиг тестируется >> только перед тем как выполнить рестар сервера: >> >> restart() { >>     configtest_q || return 6 >>     stop >>     start >> } >> >> configtest_q() { >>   $binary -t -q -c $config >> } >> >> и если тестирование конфигурации завершилось ошибкой - >> работающий nginx не останавливаается. > > Это, кстати, не работает в systemd-мире и не сказать, что бы это сильно заботило авторов: https://github.com/systemd/systemd/issues/2175 В TODO файле systemd записано: * unit files: - maybe introduce ExecRestartPre= Lennart Poettering на эту тему говорит вот что: https://lists.freedesktop.org/archives/systemd-devel/2014-July/021642.html [...] This has been a TODO item since a long time. The usecase seems valid. So far nobody found the time to implement this though. Happy to take patches... -- Best regards, Gena From maxim на nginx.com Fri Nov 10 16:19:21 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Fri, 10 Nov 2017 08:19:21 -0800 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtINC90LXQv9C+0L3Rj9GC0L3QviDQv9C+0LLQtdC00LXQvdC4?= =?UTF-8?B?0LU=?= In-Reply-To: References: <1809928.t83vvjR27v@vbart-workstation> Message-ID: On 10/11/2017 03:07, BieZax wrote: > Прошу прощения про zone, неправильно понял документацию. Теперь все > работает, как ожидалось. Спасибо за разъяснение! > Эта путаница объяснима. Первоначально этот код был только в -plus. Некоторое время назад мы перенесли его в oss. Кстати, крутая штука, которая помогает решать такие вот не совсем очевидные проблемы с балансировкой. Наверное, нам надо напрячься и написать модный блогпост с разъясениями. -- Maxim Konovalov "I'm not a software developer, but it doesn't seem as rocket science" From mdounin на mdounin.ru Fri Nov 10 18:25:19 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 10 Nov 2017 21:25:19 +0300 Subject: gzip filter failed to use preallocated memory In-Reply-To: References: <20171110113319.GJ26836@mdounin.ru> Message-ID: <20171110182519.GM26836@mdounin.ru> Hello! On Fri, Nov 10, 2017 at 09:35:02AM -0500, S.A.N wrote: > > Есть смысл разобраться, что у вас используется вместо zlib, > > Из коробки в ОС установлена пропатченная Intel библиотека zlib > https://software.intel.com/en-us/articles/how-to-use-zlib-with-intel-ipp-opertimization > > Вот что у нас выдает ldd > ldd /usr/lib64/libz.so > linux-vdso.so.1 (0x00007ffed8d7c000) > libc.so.6 => /usr/lib64/haswell/libc.so.6 (0x00007fe455d53000) > /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe455f8b000) > > > > как это что-то детектировать и аллоцировать под него память, и > > прислать патч. > > Мне сложно сказать как правильно детектировать эту библиотеку, и патч > написать я тоже не смогу (я не Си разработчик) но могу тестировать. > Intel, сделали хорошую работу, их gzip работает почти в 2 раза быстрей, не > хочется возвращаться на стандартную zlib. Я не поленился и таки скачал то, что дают по ссылке выше, и в патче вижу такое: --- zlib-1.2.8.orig/zlib.h 2017-05-29 16:04:42.703705000 +0300 +++ zlib-1.2.8/zlib.h 2017-05-29 16:09:45.779049000 +0300 @@ -187,6 +187,9 @@ #define Z_BEST_SPEED 1 #define Z_BEST_COMPRESSION 9 #define Z_DEFAULT_COMPRESSION (-1) +#if defined(WITH_IPP) +#define Z_IPP_FAST_COMPRESSION (-2) +#endif /* compression levels */ #define Z_FILTERED 1 То есть определяется новая константа, Z_IPP_FAST_COMPRESSION. Если это действительно так, то можно попробовать что-нибудь простое, вроде: diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -1025,9 +1025,11 @@ ngx_http_gzip_filter_alloc(void *opaque, return p; } +#ifndef Z_IPP_FAST_COMPRESSION ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0, "gzip filter failed to use preallocated memory: %ud of %ui", items * size, ctx->allocated); +#endif p = ngx_palloc(ctx->request->pool, items * size); Я, впрочем, подозреваю, что на самом деле там не это, а то, что лежит по адресу https://github.com/jtkukunas/zlib. Название и содержимое пакета как бы намекает: https://download.clearlinux.org/current/source/SRPMS/zlib-1.2.8.jtkv4-40.src.rpm Я когда-то смотрел на это - и пришёл к выводу, что сделать с этим ничего разумного не получается, никаких способов узнать о наличии модификаций ребята не оставили. При этом внесённые изменения очевидно противоречат документированным в zlib требованиям к памяти. Так что я решил отложить дальнейшие разбирательства до того момента, когда ребята одумаются и как-то приведут в порядок свою поделку. Но, похоже, лучше с тех пор не стало. > Возможно будет достаточно если Nginx изменит уровень ошибки, сейчас уровень > этой ошибки Alert, но это не правильно, потому что Nginx не падает и все > работает, я думаю правильно выдавать Notice, тогда можно не логировать > Notice уведомления и все будет норм? Уровень логгирования alert означает ситуацию, которая не должна возникать при нормальной работе, и означает ошибку где-то. В данном случае мы знаем причину - библиотека от Интел нарушает документированный интерфейс zlib в части требований к памяти - и этого достаточно для того, чтобы игнорировать и/или понизить уровень ошибки до менее значительного в случае использования этой библиотеки. Однако я бы предпочёл не трогать уровень логгирования для всех остальных случаев. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Sat Nov 11 13:36:18 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 11 Nov 2017 08:36:18 -0500 Subject: gzip filter failed to use preallocated memory In-Reply-To: <20171110182519.GM26836@mdounin.ru> References: <20171110182519.GM26836@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Я, впрочем, подозреваю, что на самом деле там не это, а то, что > лежит по адресу https://github.com/jtkukunas/zlib. Название и > содержимое пакета как бы намекает: > > https://download.clearlinux.org/current/source/SRPMS/zlib-1.2.8.jtkv4- > 40.src.rpm Вы правы, в OS ClearLinux библеотека zlib из этого пакета и там нет константы Z_IPP_FAST_COMPRESSION. Я написал им issue, чтобы они добавили константу, но сомневаюсь что в ближайшем будущем они что-то сделают, хотя. Может быть сделать спец флаг компиляции Nginx ./configure --with-ipp-zlib Как уже предлагали в этой ветке https://forum.nginx.org/read.php?2,252113,252114#msg-252114 Тогда мейнтейнеры смогут создавать свои сборки Nginx с 3rd party zlib. Этот вариант для вас приемлем? > Уровень логгирования alert означает ситуацию, которая не должна > возникать при нормальной работе, и означает ошибку где-то. В > данном случае мы знаем причину - библиотека от Интел нарушает > документированный интерфейс zlib в части требований к памяти - и > этого достаточно для того, чтобы игнорировать и/или понизить > уровень ошибки до менее значительного в случае использования > этой библиотеки. Однако я бы предпочёл не трогать уровень > логгирования для всех остальных случаев. Я согласен с вашими словами, но я ничего не понял что нужно мне сделать, чтобы в логах не было этой ошибки? В конфиге отключить логирование этого alert можно только если указать уровень логирование emerge error_log log/error.log emerge; Но это не хорошо, мягко говоря, или вы имели виду чтобы я сделал свой патч и изменил в коде Nginx уровень логирование? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276955,277289#msg-277289 From simplebox66 на gmail.com Sun Nov 12 19:11:34 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Sun, 12 Nov 2017 22:11:34 +0300 Subject: =?UTF-8?B?0L/QvtC80L7Qs9C40YLQtSDRgSDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtdC8?= Message-ID: Есть nginx который занимается проксированием на бекенд. как сделать так чтобы при запросе xyz.com/site1 на бекенд ушел запрос вида xyz.com, но при этом в браузере клиент видел xyz.com/site1 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Sun Nov 12 19:38:18 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Sun, 12 Nov 2017 21:38:18 +0200 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0YEg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LXQvA==?= In-Reply-To: References: Message-ID: По идее должно хватить rewrite + proxy_pass/proxy_redirect, но может зависеть от того, как криво реализован сам site1. Возможно еще понадобится http://nginx.org/en/docs/http/ngx_http_sub_module.html 2017-11-12 21:11 GMT+02:00 Иван Мишин : > Есть nginx который занимается проксированием на бекенд. > как сделать так чтобы при запросе > xyz.com/site1 > на бекенд ушел запрос вида xyz.com, но при этом в браузере клиент видел > xyz.com/site1 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Mon Nov 13 09:08:14 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 13 Nov 2017 12:08:14 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0YEg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LXQvA==?= In-Reply-To: References: Message-ID: Я догадываюсь какие модули нужны, но все мои попытки реализовать задачу провалились. Может ли кто-то подсказать более точнее? 12 ноября 2017 г., 22:38 пользователь Alex Domoradov написал: > По идее должно хватить rewrite + proxy_pass/proxy_redirect, но может > зависеть от того, как криво реализован сам site1. Возможно еще понадобится > http://nginx.org/en/docs/http/ngx_http_sub_module.html > > 2017-11-12 21:11 GMT+02:00 Иван Мишин : > >> Есть nginx который занимается проксированием на бекенд. >> как сделать так чтобы при запросе >> xyz.com/site1 >> на бекенд ушел запрос вида xyz.com, но при этом в браузере клиент видел >> xyz.com/site1 >> >> _______________________________________________ >> 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 > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 13 13:25:34 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Nov 2017 16:25:34 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0YEg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LXQvA==?= In-Reply-To: References: Message-ID: <20171113132534.GN26836@mdounin.ru> Hello! On Mon, Nov 13, 2017 at 12:08:14PM +0300, Иван Мишин wrote: > Я догадываюсь какие модули нужны, но все мои попытки реализовать задачу > провалились. > Может ли кто-то подсказать более точнее? Более точнее так: - В простейшем случае задача сводится к тому, чтобы сделать proxy_pass внутри соответствующего location'а: location /site1/ { proxy_pass http://xyz.com/; } Тут важно обратить внимание на "/" в proxy_pass - он говорит nginx'у, что при проксировании следует менять префикс "/site1/" в исходном URI запроса на "/". Так будет работать, если бэкенд использует относительные адреса для ресурсов, возвращает предсказуемые перенаправления (см. proxy_redirect) и так далее. - В наиболее сложном случае абсолютные адреса оказываются зашиты не только в возвращаемых html-страницах (которые, при желании, можно пытаться править с помощью sub_filter), но и в каких-нибудь бинарных/проприетарных swf-файлах. И поставленная задача вообще не решается. Где именно между этими крайними положениями находится ваш сайт - известно только вам. А если не известно - то и выяснять, соответственно, вам. Постепенно дополняя простейшую конфигурацию выше различными подпорками для решения возникающих проблем. Ну и не следует забывать, что в общем случае - задача не решается. И где-то в тот момент, когда возникает необходимость менять содержимое возвращаемых страниц с помощью sub_filter - имеет смысл задуматься о том, чтобы пойти и переделать бэкенд. Или даже не переделать, а просто разобраться с ним чуть получше - часто бывает, что бэкенд всё умеет, просто его нужно соответствующим образом сконфигурировать. -- Maxim Dounin http://mdounin.ru/ From coddoc на mail.ru Mon Nov 13 14:07:53 2017 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Mon, 13 Nov 2017 17:07:53 +0300 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4g0LTQtdCx0LDQs9GD?= Message-ID: <1510582073.288995275@f169.i.mail.ru> Доброго времени суток! Подскажите, плиз, где можно почитать нормальную документацию про сообщения в дебаг логе. Перерыл весь гугол, ничего толком нет. Честно, надоело играть в угадайку. Например, что означают такие записи в режиме debug_http: 1. 2017/11/13 07:41:37 [debug] 624#0: *244736 rewrite phase: 3     2017/11/13 07:41:37 [debug] 624#0: *244736 post rewrite phase: 4     2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 5     2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 6     2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 7     2017/11/13 07:41:37 [debug] 624#0: *244736 generic phase: 8     2017/11/13 07:41:37 [debug] 624#0: *244736 http script var: "Q^Y,m"     2017/11/13 07:41:37 [debug] 624#0: *244736 limit conn: 4B30596F 1     2017/11/13 07:41:37 [debug] 624#0: *244736 access phase: 9     2017/11/13 07:41:37 [debug] 624#0: *244736 access phase: 10     2017/11/13 07:41:37 [debug] 624#0: *244736 post access phase: 11 2. 2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: "Connection: close^M"     2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""     2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""     2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: ""     2017/11/13 07:41:37 [debug] 624#0: *244736 http script copy: "" Последние 4 пустых строки 3. 2017/11/13 07:41:37 [debug] 624#0: *244736 http cleanup add: 0000000001F02220     2017/11/13 07:41:37 [debug] 624#0: *244736 get rr peer, try: 1     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream connect: -2     2017/11/13 07:41:37 [debug] 624#0: *244736 http finalize request: -4, "/?" a:1, c:2     2017/11/13 07:41:37 [debug] 624#0: *244736 http request count:2 blk:0     2017/11/13 07:41:37 [debug] 624#0: *244736 http run request: "/?"     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream check client, write event:1, "/"     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream recv(): -1 (11: Resource temporarily unavailable) Здесь особо интересует (11: Resource temporarily unavailable). Запрос делался в корень методом HEAD Потому что дальше, вроде бы, все в порядке:     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream request: "/?"     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request handler     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream send request body     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream request: "/?"     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream process header     2017/11/13 07:41:37 [debug] 624#0: *244736 http proxy status 200 "200 OK" 4. 2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter: l:1 f:0 s:298     2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter limit 0     2017/11/13 07:41:37 [debug] 624#0: *244736 http write filter 0000000000000000     2017/11/13 07:41:37 [debug] 624#0: *244736 finalize http upstream request: 0     2017/11/13 07:41:37 [debug] 624#0: *244736 finalize http proxy request     2017/11/13 07:41:37 [debug] 624#0: *244736 free rr peer 1 0     2017/11/13 07:41:37 [debug] 624#0: *244736 close http upstream connection: 5     2017/11/13 07:41:37 [debug] 624#0: *244736 http finalize request: 0, "/?" a:1, c:1     2017/11/13 07:41:37 [debug] 624#0: *244736 set http keepalive handler     2017/11/13 07:41:37 [debug] 624#0: *244736 http close request Спасибо. -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 13 14:37:50 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Nov 2017 17:37:50 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC00LXQsdCw0LPRgw==?= In-Reply-To: <1510582073.288995275@f169.i.mail.ru> References: <1510582073.288995275@f169.i.mail.ru> Message-ID: <20171113143750.GP26836@mdounin.ru> Hello! On Mon, Nov 13, 2017 at 05:07:53PM +0300, CoDDoC wrote: > Доброго времени суток! > Подскажите, плиз, где можно почитать нормальную документацию про сообщения в дебаг логе. > Перерыл весь гугол, ничего толком нет. Честно, надоело играть в угадайку. Всё подробно документировано в исходниках, на языке C. И это единственное место, где оно когда-либо будет документировано, ибо debug-логи - в первую очередь для разработчиков, и разработчики туда выводят то, что им нужно/важно там увидеть. То, что нужно видеть и понимать администраторам - выводится на уровне info и выше, и там выводимый текст достаточен для понимания смысла сообщения. [...] >     2017/11/13 07:41:37 [debug] 624#0: *244736 http upstream recv(): -1 (11: Resource temporarily unavailable) > > Здесь особо интересует (11: Resource temporarily unavailable). Запрос делался в корень методом HEAD EAGAIN - это нормально для работы с неблокирующимися сокетами. -- Maxim Dounin http://mdounin.ru/ From simplebox66 на gmail.com Mon Nov 13 16:38:45 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 13 Nov 2017 19:38:45 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QvNC+0LPQuNGC0LUg0YEg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LXQvA==?= In-Reply-To: <20171113132534.GN26836@mdounin.ru> References: <20171113132534.GN26836@mdounin.ru> Message-ID: Максим, большое спасибо за развернутый ответ, осбенно за > > В наиболее сложном случае абсолютные адреса оказываются зашиты > не только в возвращаемых html-страницах (которые, при желании, > можно пытаться править с помощью sub_filter), но и в каких-нибудь > бинарных/проприетарных swf-файлах. И поставленная задача вообще > не решается. Это как раз мой случай оказался, поэтому свою задачу решу лучше через поддомены. 13 ноября 2017 г., 16:25 пользователь Maxim Dounin написал: > Hello! > > On Mon, Nov 13, 2017 at 12:08:14PM +0300, Иван Мишин wrote: > > > Я догадываюсь какие модули нужны, но все мои попытки реализовать задачу > > провалились. > > Может ли кто-то подсказать более точнее? > > Более точнее так: > > - В простейшем случае задача сводится к тому, чтобы сделать > proxy_pass внутри соответствующего location'а: > > location /site1/ { > proxy_pass http://xyz.com/; > } > > Тут важно обратить внимание на "/" в proxy_pass - он говорит > nginx'у, что при проксировании следует менять префикс "/site1/" в > исходном URI запроса на "/". > > Так будет работать, если бэкенд использует относительные адреса > для ресурсов, возвращает предсказуемые перенаправления (см. > proxy_redirect) и так далее. > > - В наиболее сложном случае абсолютные адреса оказываются зашиты > не только в возвращаемых html-страницах (которые, при желании, > можно пытаться править с помощью sub_filter), но и в каких-нибудь > бинарных/проприетарных swf-файлах. И поставленная задача вообще > не решается. > > Где именно между этими крайними положениями находится ваш сайт - > известно только вам. А если не известно - то и выяснять, > соответственно, вам. Постепенно дополняя простейшую конфигурацию > выше различными подпорками для решения возникающих проблем. > > Ну и не следует забывать, что в общем случае - задача не решается. > И где-то в тот момент, когда возникает необходимость менять > содержимое возвращаемых страниц с помощью sub_filter - имеет смысл > задуматься о том, чтобы пойти и переделать бэкенд. Или даже не > переделать, а просто разобраться с ним чуть получше - часто > бывает, что бэкенд всё умеет, просто его нужно соответствующим > образом сконфигурировать. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Nov 14 02:38:25 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:38:25 -0500 Subject: roller connector Message-ID: <4d5fd3d5ee3f43bd153dcee22c2e3914.NginxMailingListRussian@forum.nginx.org> Our History Ningbo Defa aluminum profile accessories Co.,Ltd. is located in the southern outskirts of Ningbo City, near Ningbo airport and seaport, very convenient for transportation. The company is about 12,000 square meters and has already invested total RMB 8,600,000 for its products and equipments in the past 10 years. Our Factory DFH is the mother manufacturer company of three factories: Aluminum Profile Accessories Factory, Pipe Rack System Factory and Metal Tool Factory. Our Product DFH specialized in producing and developing aluminum profile accessories and pipe tack systems. Product Application All the items made in DFH can be widely used in automation area. Our Certificate Production Equipment Production Market The products are mainly exported to more than 20 abroad countries and regions such as Germany, France, Italy and other European countries. We have also entrusted several agents in other countries or regions, such as Pano Metal from Turkey. DFH has won a good reputation from customers all over the world for decades of years. In recent years, to meet broad market, DFH keeps continuous innovation and broaden the market, product design, material quality, processing technology, product standards, a series of stringent monitoring processes to be perfect, to meet the requirements of our customers. Our service All of our products are strictly made according to international quality management system ISO9001-2000 and also inspected strictly according to customer's requirements before delivery. We are doing our best to make sure every part sending to our customers are perfect. Any quality feedbacks after customer's collecting the goods will be highly treated and solved by DFH side in a shortest time. We believe that "only customer's satisfaction can really bring DFH's satisfaction". Thus, our efforts starting from quotation to after-sales service will be well recorded and all suggestions from customers will be highly appreciated. We sincerely hope to establish business relationship with any one or any company on the basis of mutual benefit and equality. roller connector website:http://www.chinadfh.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277317,277317#msg-277317 From nginx-forum на forum.nginx.org Tue Nov 14 02:38:43 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:38:43 -0500 Subject: 6.6HP diesel engine supplier Message-ID: <597cfeb8d8cf27e83aaf63c66f2fcf37.NginxMailingListRussian@forum.nginx.org> YANCHENG JIANGYANG ENGINE CO., LTD. was established in Yancheng city, Jiangsu province in 1991, specializing in designing and producing top quality diesel engines from 3 hp to 33 hp and various kinds of generating sets, such as automatic, trailer, sound proof, from 0.5kw to 1500kw. We also supply water pump set, sprayer, alternator and spare parts. JYDE believes in “Basis on quality, and win from credit” and is always committed to providing customers with high-quality products and meritorious services to meet demands of different customers. JYDE products have exported to to USA, Canada, Vietnam, Indonesia and the other 20 countries from Southeast Asia, middle east and Africa, and always enjoy good reputations. JYDE factory has 30000 square meters’ plant in independent building, more than 200 senior staffs, integrative production line and QC inspection system. JYDE could create more than 50000 sets of agriculture products yearly, and we have already built a strong and long term business relationship with Indonesia Dongfeng group, Vietnam south company, and etc. JYDE small horse power diesel engine products are widely used in farm, mine, hospital and school as a reserved power source for emergent case, such as handheld and small four-wheel tractors, engineering machineries, three-wheel vehicles, generator sets, water pumps, air compressors, gardening machines, the processing of agricultural and side-line products. JYDE has passed many certificates such as CE , ISO, SGS, SONCAP and so on. JYDE hopes to establish long-term cooperative relationships with each other and achieve win-win. JYDE will be the ideal partner for you. 6.6HP diesel engine supplier website:http://www.china-dieselengine.com/ website2:http://www.china-hotsaledieselengine.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277318,277318#msg-277318 From nginx-forum на forum.nginx.org Tue Nov 14 02:39:02 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:39:02 -0500 Subject: China universal fuel pump Message-ID: <036f725c2a6f2f48e5e6a2ffc3afe9d8.NginxMailingListRussian@forum.nginx.org> About UsChina universal fuel pump website:http://www.chinadkk.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277319,277319#msg-277319 From nginx-forum на forum.nginx.org Tue Nov 14 02:39:37 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:39:37 -0500 Subject: China Elevator Traction Machine suppliers Message-ID: <28668add20aed43336883417e68aac01.NginxMailingListRussian@forum.nginx.org> Our service Strong technical team with years of experience in elevator commissioning Rigorous and efficient service process of the Marketing and Aftermarket Department China Elevator Traction Machine suppliers website:http://www.chinaelevatorpart.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277321,277321#msg-277321 From nginx-forum на forum.nginx.org Tue Nov 14 02:39:22 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:39:22 -0500 Subject: Active Ingredient I Message-ID: <060d781998e709a29dc5eebc2540ff29.NginxMailingListRussian@forum.nginx.org> Xi'an Rainbow Bio-Tech Co.,Ltd is one of the leading China rivanol manufacturers, welcome to wholesale cheap rivanol, rivanol extracts powder from our factory. RIVANOL 1.CAS No.: 1837-57-6 & 6402-23-9 2.EINECS No.: 217-408-1 3.Color: White 4.MF: C15H15N3O.C3H6O3 5.Specification ItemsUnitsCP2005EP5JP14DAB2000 Description Yellow Crystalline PowderYellow Crystalline PowderYellow Crystalline PowderYellow Crystalline Powder Appearance of Solution Clear Heavy Metals%≤0.003≤0.005≤0.002≤0.01 Sulphated ash%≤0.100≤0.100≤0.100≤0.200 Loss on Drying%≤5.54.5-5.5 4.5-5.5 Chloride%≤0.025 ≤0.026≤0.024 Sulfate%≤0.500 Nothing≤0.072 PH ValuePH6.0-7.05.5-7.0 5.5-7.0 Assay%≥99.099.0-101.0≥99.098.5-100.5 Dissociated acid NaOH dosage ≤0.3ml Ammonium NothingNothing Fatty Acid Nothing Impurities (HPLC) Each single impurity max. 0.3% Each single impurity max. 0.5% Sum of impurities max. 1.0% Sum of impurities max. 1.0%Active Ingredient I website:http://www.chinaebio.com/active-ingredient-i-1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277320,277320#msg-277320 From nginx-forum на forum.nginx.org Tue Nov 14 02:39:53 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:39:53 -0500 Subject: Customized Three Phase DIN Rail Energy Meter Message-ID: As one of the professional manufacturers and suppliers of quality [[productcatename]], Baibu Smart Technology can offer you customized service and wholesale service at competitive price. We are known as a credible China [[productcatename]] exporter. Just be free to buy smart products made in China from us. As one of the professional manufacturers and suppliers of quality three phase din rail mounted multi- tariff kwh meter, Baibu Smart Technology can offer you customized service and wholesale service at competitive price. We are known as a credible China three phase din rail mounted multi- tariff kwh meter exporter. Just be free to buy smart products made in China from us.Customized Three Phase DIN Rail Energy Meter website:http://www.china-energymeters.com/electronic-energy-meter/din-rail-energy-meter/three-phase-din-rail-energy-meter/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277322,277322#msg-277322 From nginx-forum на forum.nginx.org Tue Nov 14 02:40:08 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:40:08 -0500 Subject: Microfiber Cloth Message-ID: Baibu Smart Technology is a high-tech enterprise invested by Cixi Eden Electric Power Meter Co.,LTD, professionally involved in designing and manufacturing wide range electronic smart energy meters and electronic smart control products. These include electronic smart energy meters, electronic KWH meters, accessories of energy meter and electronic smart control modules etc. We have been designed and offered energy meter since 1997. After many years of accumulation, we have established a professional and experienced team of technology and marketing, who will continually support us to offer high quality products. We are the quality supplier of State Grid Corporation of China. Till now we've been offered more than 12,000,000 pcs electronic energy meters to State Grid Corporation. Meanwhile we also export our meters and accessories to oversea market such as Germany, England, Italy, Poland, Russia, Czech, Canada, Vietnam, Thailand, Philippines, India, Brazil, Chile, Mexico, Columbia, and Ecuador etc. After development of 20 years, now we have established more perfect product testing lab, manufacturing manage system of electronic products, production quality management and traceability system, including more perfect production facilities and modern testing equipment. We have passed ISO9001 Quality System, ISO14000 Environmental System and ISO18000 Occupation Health in 2000. All of above can support us to offer high quality products for clients. Furthermore, we also dedicated to designing and offering other electronic smart control products such as smart Microwave Motion sensor, smart timer, smart timing counter, smart security control products and smart home appliance control modules etc.Microfiber Cloth website:http://www.chinaeyeglasscases.com/cleaning-cloth/microfiber-cloth/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277323,277323#msg-277323 From nginx-forum на forum.nginx.org Tue Nov 14 02:40:53 2017 From: nginx-forum на forum.nginx.org (gkgk21v) Date: Mon, 13 Nov 2017 21:40:53 -0500 Subject: lift installation quotation Message-ID: Benefits • Efficient It will lift the rails with double ends, one end up while the other end comes down for another new rail. • Quick Setup Only require two drilling holes in machine room for the two lifting ends. The frame will only need 4 expansion screw to position. • Remote control It provides remote which can be used for 1000m. Then the worker can control the lifting system directly in the false car. • Save Cost It will help save one person in the machine room who control the winches before. And double ends lifting will help save more time from lifting. • Full Adjustability The lifting system designed adjustable to any kind of elevator shaft. • Increased Safety: Reduces Your Liability Safety devices and emergency stop button as part of the lifting system increases job-site safety Main parameters: Lifting System Rated Capacity: 200kg Power Supply: 380V, 50Hz, 3 phase Motor Power: 1.5kw Lifting Speed: 18m/min Remote Height: 300m Wire Rope: 6mm dia. (Anti-spinning) Safety Device: Emergency Stop, Top-Limit Switchlift installation quotation website:http://www.chinafalsecar.com/elevator-installation/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277324,277324#msg-277324 From mdounin на mdounin.ru Wed Nov 15 04:33:55 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 15 Nov 2017 07:33:55 +0300 Subject: gzip filter failed to use preallocated memory In-Reply-To: References: <20171110182519.GM26836@mdounin.ru> Message-ID: <20171115043355.GY26836@mdounin.ru> Hello! On Sat, Nov 11, 2017 at 08:36:18AM -0500, S.A.N wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Я, впрочем, подозреваю, что на самом деле там не это, а то, что > > лежит по адресу https://github.com/jtkukunas/zlib. Название и > > содержимое пакета как бы намекает: > > > > https://download.clearlinux.org/current/source/SRPMS/zlib-1.2.8.jtkv4- > > 40.src.rpm > > Вы правы, в OS ClearLinux библеотека zlib из этого пакета и там нет > константы Z_IPP_FAST_COMPRESSION. > Я написал им issue, чтобы они добавили константу, но сомневаюсь что в > ближайшем будущем они что-то сделают, хотя. > > Может быть сделать спец флаг компиляции Nginx ./configure --with-ipp-zlib > Как уже предлагали в этой ветке > https://forum.nginx.org/read.php?2,252113,252114#msg-252114 > > Тогда мейнтейнеры смогут создавать свои сборки Nginx с 3rd party zlib. > Этот вариант для вас приемлем? Это не выглядит хорошим решением. Особенно с учётом того, что IPP zlib и jtk zlib - это два разных zlib'а. > > Уровень логгирования alert означает ситуацию, которая не должна > > возникать при нормальной работе, и означает ошибку где-то. В > > данном случае мы знаем причину - библиотека от Интел нарушает > > документированный интерфейс zlib в части требований к памяти - и > > этого достаточно для того, чтобы игнорировать и/или понизить > > уровень ошибки до менее значительного в случае использования > > этой библиотеки. Однако я бы предпочёл не трогать уровень > > логгирования для всех остальных случаев. > > Я согласен с вашими словами, но я ничего не понял что нужно мне сделать, > чтобы в логах не было этой ошибки? > В конфиге отключить логирование этого alert можно только если указать > уровень логирование emerge > error_log log/error.log emerge; > Но это не хорошо, мягко говоря, или вы имели виду чтобы я сделал свой патч и > изменил в коде Nginx уровень логирование? Патч ниже по первой ошибке преаллокации пытается предполагать, что мы работаем с jtk zlib, и работает соответственно. Если и это не помогло - тогда уже начинает писать в лог alert'ы. # HG changeset patch # User Maxim Dounin # Date 1510720355 -10800 # Wed Nov 15 07:32:35 2017 +0300 # Node ID 63b85af82bb1ad8b7d29979619b22ecebd962c66 # Parent 9ba0a577601b7c1b714eb088bc0b0d21c6354699 Gzip: support for a zlib variant from Intel. A zlib variant from Intel as available from https://github.com/jtkukunas/zlib uses 64K hash instead of scaling it from the specified memory level, and also uses 16-byte padding in one of the window-sized memory buffers, and can force window bits to 13 if compression level is set to 1 and appropriate compile options are used. As a result, nginx complained with "gzip filter failed to use preallocated memory" alerts. This change improves deflate_state allocation detection by testing that items is 1 (deflate_state is the only allocation where items is 1). Additionally, on first failure to use preallocated memory we now assume that we are working with the Intel's modified zlib, and switch to using appropriate preallocations. If this does not help, we complain with the usual alerts. Previous version of this patch was published at http://mailman.nginx.org/pipermail/nginx/2014-July/044568.html. The zlib variant in question is used by default in ClearLinux from Intel, see http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060421.html, http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060544.html. diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -57,6 +57,7 @@ typedef struct { unsigned nomem:1; unsigned gzheader:1; unsigned buffering:1; + unsigned intel:1; size_t zin; size_t zout; @@ -233,6 +234,8 @@ static ngx_str_t ngx_http_gzip_ratio = static ngx_http_output_header_filter_pt ngx_http_next_header_filter; static ngx_http_output_body_filter_pt ngx_http_next_body_filter; +static ngx_uint_t ngx_http_gzip_assume_intel; + static ngx_int_t ngx_http_gzip_header_filter(ngx_http_request_t *r) @@ -527,7 +530,27 @@ ngx_http_gzip_filter_memory(ngx_http_req * *) 5920 bytes on amd64 and sparc64 */ - ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); + if (!ngx_http_gzip_assume_intel) { + ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); + + } else { + /* + * A zlib variant from Intel, https://github.com/jtkukunas/zlib. + * It can force window bits to 13 for fast compression level, + * on processors with SSE 4.2 it uses 64K hash instead of scaling + * it from the specified memory level, and also introduces + * 16-byte padding in one out of the two window-sized buffers. + */ + + if (conf->level == 1) { + wbits = ngx_max(wbits, 13); + } + + ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) + + (1 << (ngx_max(memlevel, 8) + 8)) + + (1 << (memlevel + 8)); + ctx->intel = 1; + } } @@ -1003,7 +1026,7 @@ ngx_http_gzip_filter_alloc(void *opaque, alloc = items * size; - if (alloc % 512 != 0 && alloc < 8192) { + if (items == 1 && alloc % 512 != 0 && alloc < 8192) { /* * The zlib deflate_state allocation, it takes about 6K, @@ -1025,9 +1048,14 @@ ngx_http_gzip_filter_alloc(void *opaque, return p; } - ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0, - "gzip filter failed to use preallocated memory: %ud of %ui", - items * size, ctx->allocated); + if (ctx->intel) { + ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0, + "gzip filter failed to use preallocated memory: " + "%ud of %ui", items * size, ctx->allocated); + + } else { + ngx_http_gzip_assume_intel = 1; + } p = ngx_palloc(ctx->request->pool, items * size); -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Nov 15 15:58:16 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 15 Nov 2017 10:58:16 -0500 Subject: gzip filter failed to use preallocated memory In-Reply-To: <20171115043355.GY26836@mdounin.ru> References: <20171115043355.GY26836@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Патч ниже по первой ошибке преаллокации пытается предполагать, что > мы работаем с jtk zlib, и работает соответственно. Если и это не > помогло - тогда уже начинает писать в лог alert'ы. Сработало, спасибо! В логе сообщений уже нет, других изменений в поведении Nginx не заметил, этот патч войдет в следующую версию Nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276955,277335#msg-277335 From mdounin на mdounin.ru Wed Nov 15 19:16:55 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 15 Nov 2017 22:16:55 +0300 Subject: gzip filter failed to use preallocated memory In-Reply-To: References: <20171115043355.GY26836@mdounin.ru> Message-ID: <20171115191655.GA26836@mdounin.ru> Hello! On Wed, Nov 15, 2017 at 10:58:16AM -0500, S.A.N wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Патч ниже по первой ошибке преаллокации пытается предполагать, что > > мы работаем с jtk zlib, и работает соответственно. Если и это не > > помогло - тогда уже начинает писать в лог alert'ы. > > Сработало, спасибо! > В логе сообщений уже нет, других изменений в поведении Nginx не заметил, > этот патч войдет в следующую версию Nginx? Возможно. Я отправил его коллегам на review, если возражений не будет - закоммичу. -- Maxim Dounin http://mdounin.ru/ From bloodjazman на gmail.com Thu Nov 16 13:24:31 2017 From: bloodjazman на gmail.com (Eugene Klimov) Date: Thu, 16 Nov 2017 18:24:31 +0500 Subject: =?UTF-8?B?0L/QvtGH0LXQvNGDINCyINC70L7QsyDQvdC1INC/0LjRiNC10YLRgdGPIHJlcXVl?= =?UTF-8?B?c3RfYm9keSA/?= Message-ID: Всем привет, скажите пожалуйста, а какие есть ограничения на запись в лог request_body кроме тех кто написаны вот тут? http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_request_body # nginx -v nginx version: nginx/1.12.0 у меня вот есть такой конфиг (не мое. в наследство достался) log_format format_json escape=json '{"remote_addr":"$remote_addr","remote_user":"$remote_user","time_local":"$time_iso8601","msec": $msec,"request":"$request","request_uri":"$request_uri","status":"$status","body_bytes_sent":"$body_bytes_sent", "referer":"$http_referer","user_agent":"$http_user_agent", "req_time":$request_time,"uid_got":"$uid_got","uid_set":"$uid_set", "apic":"$cookie_spjsapicall","sndraw":"$cookie_spsenderaway","upstream_time": $upstream_response_time, "request_body": "$request_body", "content_length":"$content_length","request_body_file":"$request_body_file","upstream_addr":"$upstream_addr","ssl_protocol":"$ssl_protocol"}'; server { listen 80; server_name xxx.ru; location ~ ^/integration/xxx/ { proxy_pass http://mybackend_integrations_xxx; proxy_set_header Host $host; proxy_http_version 1.1; proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600; access_log /home/nginx/log/xxx-integration-json.log format_json; client_max_body_size 30m; client_body_buffer_size 1m; client_body_in_file_only off; client_body_in_single_buffer on; } } почему в логе у меня пишется вот такое? "request_body": "","content_length":"105715","request_body_file":"/var/cache/nginx/client_temp/0006557331","upstream_addr":"10.216.130.28:80","ssl_protocol":""} выглядит так будто директивы client_body_* для моего location просто не срабатывают и все все равно пишется в tmp файл? что еще я забыл? From mdounin на mdounin.ru Thu Nov 16 16:10:46 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 16 Nov 2017 19:10:46 +0300 Subject: =?UTF-8?B?UmU6INC/0L7Rh9C10LzRgyDQsiDQu9C+0LMg0L3QtSDQv9C40YjQtdGC0YHRjyBy?= =?UTF-8?B?ZXF1ZXN0X2JvZHkgPw==?= In-Reply-To: References: Message-ID: <20171116161046.GD26836@mdounin.ru> Hello! On Thu, Nov 16, 2017 at 06:24:31PM +0500, Eugene Klimov wrote: > Всем привет, скажите пожалуйста, а какие есть ограничения на запись в > лог request_body кроме тех кто написаны вот тут? > http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_request_body > > # nginx -v > nginx version: nginx/1.12.0 > > у меня вот есть такой конфиг (не мое. в наследство достался) > > > log_format format_json escape=json > '{"remote_addr":"$remote_addr","remote_user":"$remote_user","time_local":"$time_iso8601","msec": > $msec,"request":"$request","request_uri":"$request_uri","status":"$status","body_bytes_sent":"$body_bytes_sent", > "referer":"$http_referer","user_agent":"$http_user_agent", > "req_time":$request_time,"uid_got":"$uid_got","uid_set":"$uid_set", > "apic":"$cookie_spjsapicall","sndraw":"$cookie_spsenderaway","upstream_time": > $upstream_response_time, "request_body": "$request_body", > "content_length":"$content_length","request_body_file":"$request_body_file","upstream_addr":"$upstream_addr","ssl_protocol":"$ssl_protocol"}'; > > server { > listen 80; > server_name xxx.ru; > > location ~ ^/integration/xxx/ { > proxy_pass > http://mybackend_integrations_xxx; > proxy_set_header Host $host; > proxy_http_version 1.1; > proxy_connect_timeout 600; > proxy_send_timeout 600; > proxy_read_timeout 600; > send_timeout 600; > > access_log /home/nginx/log/xxx-integration-json.log format_json; > client_max_body_size 30m; > client_body_buffer_size 1m; > client_body_in_file_only off; > client_body_in_single_buffer on; > } > > } > > почему в логе у меня пишется вот такое? > > "request_body": > "","content_length":"105715","request_body_file":"/var/cache/nginx/client_temp/0006557331","upstream_addr":"10.216.130.28:80","ssl_protocol":""} > > > выглядит так будто директивы client_body_* для моего location просто > не срабатывают и все все равно пишется в tmp файл? > что еще я забыл? А запрос при этом был куда? В смысле - тело запроса читалось в контексте приведённого location'а, или в этот location запрос перенаправили с помощью какого-нибудь X-Accel-Redirect, и тело уже было прочитано? -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Thu Nov 16 16:14:40 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 16 Nov 2017 18:14:40 +0200 Subject: =?UTF-8?B?UmU6INC/0L7Rh9C10LzRgyDQsiDQu9C+0LMg0L3QtSDQv9C40YjQtdGC0YHRjyBy?= =?UTF-8?B?ZXF1ZXN0X2JvZHkgPw==?= In-Reply-To: References: Message-ID: А запрос то какой поступает? 2017-11-16 15:24 GMT+02:00 Eugene Klimov : > Всем привет, скажите пожалуйста, а какие есть ограничения на запись в > лог request_body кроме тех кто написаны вот тут? > http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_request_body > > # nginx -v > nginx version: nginx/1.12.0 > > у меня вот есть такой конфиг (не мое. в наследство достался) > > > log_format format_json escape=json > '{"remote_addr":"$remote_addr","remote_user":"$remote_user", > "time_local":"$time_iso8601","msec": > $msec,"request":"$request","request_uri":"$request_uri"," > status":"$status","body_bytes_sent":"$body_bytes_sent", > "referer":"$http_referer","user_agent":"$http_user_agent", > "req_time":$request_time,"uid_got":"$uid_got","uid_set":"$uid_set", > "apic":"$cookie_spjsapicall","sndraw":"$cookie_spsenderaway" > ,"upstream_time": > $upstream_response_time, "request_body": "$request_body", > "content_length":"$content_length","request_body_file":"$ > request_body_file","upstream_addr":"$upstream_addr","ssl_ > protocol":"$ssl_protocol"}'; > > server { > listen 80; > server_name xxx.ru; > > location ~ ^/integration/xxx/ { > proxy_pass > http://mybackend_integrations_xxx; > proxy_set_header Host $host; > proxy_http_version 1.1; > proxy_connect_timeout 600; > proxy_send_timeout 600; > proxy_read_timeout 600; > send_timeout 600; > > access_log /home/nginx/log/xxx-integration-json.log > format_json; > client_max_body_size 30m; > client_body_buffer_size 1m; > client_body_in_file_only off; > client_body_in_single_buffer on; > } > > } > > почему в логе у меня пишется вот такое? > > "request_body": > "","content_length":"105715","request_body_file":"/var/ > cache/nginx/client_temp/0006557331","upstream_addr":"10.216.130.28:80 > ","ssl_protocol":""} > > > выглядит так будто директивы client_body_* для моего location просто > не срабатывают и все все равно пишется в tmp файл? > что еще я забыл? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sargaskn на gmail.com Fri Nov 17 12:17:47 2017 From: sargaskn на gmail.com (Sargas) Date: Fri, 17 Nov 2017 14:17:47 +0200 Subject: Kubernetes ingress In-Reply-To: References: Message-ID: Вопрос еще не актуален :( 10 ноября 2017 г., 15:17 пользователь Sargas написал: > по strace видно что процесс обслуживает соединения > https://pastebin.com/N0Y4AANj > И вообщем-то процессы завершаются через какое-то время. Но время не > прогнозируемое. И в случае DEV окружения релоады nginx могут каждых 10 > минут происходить. > > Хотелось бы понимать что еще покрутить можно. > > 8 ноября 2017 г., 14:45 пользователь Sargas написал: > > Приветствую! >> >> Использую ingress https://github.com/nginxinc/kubernetes-ingress , >> возникла проблема с websocket'ами. После релоада nginx остаются висеть >> воркеры >> nginx 762 0.0 0.0 89284 11292 ? S Nov07 0:15 nginx: >> worker process is shutting down >> nginx 26321 0.0 0.0 88008 10196 ? S Nov07 0:18 nginx: >> worker process is shutting down >> >> Разработчики добавили в сервис с nodejs отправку websocket ping-фреймов >> для проверки работоспособности соединения, но воркеры всё равно могут >> висеть от нескольких часов до суток. >> Я добавил в конфиг worker_shutdown_timeout 1m; >> http://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout >> Я ожидал что через минуту все воркеры завершатся, но этого не происходит. >> >> Конфиг nginx.conf https://pastebin.com/zQxC4B1J >> Конфиг server {} https://pastebin.com/mj8egpXJ >> >> nginx version: nginx/1.13.3 >> built by gcc 6.3.0 20170516 (Debian 6.3.0-18) >> built with OpenSSL 1.1.0f 25 May 2017 >> TLS SNI support enabled >> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx >> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf >> --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log >> --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock >> --http-client-body-temp-path=/var/cache/nginx/client_temp >> --http-proxy-temp-path=/var/cache/nginx/proxy_temp >> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp >> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp >> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx >> --group=nginx --with-compat --with-file-aio --with-threads >> --with-http_addition_module --with-http_auth_request_module >> --with-http_dav_module --with-http_flv_module --with-http_gunzip_module >> --with-http_gzip_static_module --with-http_mp4_module >> --with-http_random_index_module --with-http_realip_module >> --with-http_secure_link_module --with-http_slice_module >> --with-http_ssl_module --with-http_stub_status_module >> --with-http_sub_module --with-http_v2_module --with-mail >> --with-mail_ssl_module --with-stream --with-stream_realip_module >> --with-stream_ssl_module --with-stream_ssl_preread_module >> --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/build >> er/debuild/nginx-1.13.3/debian/debuild-base/nginx-1.13.3=. >> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong >> -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' >> --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro >> -Wl,-z,now -Wl,--as-needed -pie' >> >> >> Подскажите, пожалуйста, должны ли по истечению таймаута >> worker_shutdown_timeout все старые воркеры завершать свою работу? Если >> должны, то в какую сторону копать и что проверить ? >> >> 10 апреля 2017 г., 16:04 пользователь Michael Pleshakov < >> michael на nginx.com> написал: >> >> Здравствуйте, Sargas >>> >>> Проект будет поддерживаться: будем улучшать текущие возможности и >>> исправлять найденные дефекты. Новые возможности -- расширения Ingress через >>> аннотации -- в основном, добавляются сообществом. Проект является открытым >>> и мы с радостью принимаем пулл реквесты. >>> >>> --Михаил >>> >>> 2017-04-09 0:29 GMT+01:00 Sargas : >>> >>>> Здравствуйте. >>>> >>>> Скажите, пожалуйста, а есть ли у вас какие-то планы по развитию >>>> https://github.com/nginxinc/kubernetes-ingress ? >>>> >>>> Для разработки начали использовать ваш, сейчас думаем что выбирать. Ваш >>>> или тот что делают в сообществе https://github.com/kubernetes/ingress >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Nov 17 12:50:30 2017 From: nginx-forum на forum.nginx.org (KycKyc) Date: Fri, 17 Nov 2017 07:50:30 -0500 Subject: =?UTF-8?B?0KHQvtC10LTQuNC90LXQvdC40LUg0YEgVXBzdHJlYW0g0LfQsNC90LjQvNCw0LU=?= =?UTF-8?B?0YIgMSDRgdC10LrRg9C90LTRgy4=?= Message-ID: <428a8a2b8d1b9139beb31c6d5a6609e8.NginxMailingListRussian@forum.nginx.org> Здравствуйте, столкнулся со следующей проблемой. Связка nginx + uwsgi, на продакшн сервере соединение с upstream($upstream_connect_time) занимает 1 секунду (+-3ms), бывает раз в 20-30 запросов проскакивает запрос с временем соединения в 0 сек, промежуточных значений замечено небыло. Запросы логируются только с 1го IP. Upstream обслуживает http API. Статика отдается моментально. Соединение с websocket upstream (тоже uwsgi) сервером занимает 0 секунд. Так же, в системном журнале никаких предупреждений нет. В чем может быть проблема ? nginx.conf: https://pastebin.com/WipnHPkd Конфиг сервера: https://pastebin.com/bfVCxP78 Текущий stub_status: Active connections: 19993 server accepts handled requests 359071 359071 1362273 Reading: 0 Writing: 10343 Waiting: 9639 Для примера залогировал один запрос. Nginx debug log: https://pastebin.com/sN30E6Ye tcpdump: https://imgur.com/a/ntC4h Версия nginx: nginx version: nginx/1.13.6 built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) built with OpenSSL 1.0.2g 1 Mar 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' До этого стоял 1.12.1, было тоже самое. Спасибо ! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277361,277361#msg-277361 From mdounin на mdounin.ru Fri Nov 17 14:18:57 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 17 Nov 2017 17:18:57 +0300 Subject: =?UTF-8?B?UmU6INCh0L7QtdC00LjQvdC10L3QuNC1INGBIFVwc3RyZWFtINC30LDQvdC40Lw=?= =?UTF-8?B?0LDQtdGCIDEg0YHQtdC60YPQvdC00YMu?= In-Reply-To: <428a8a2b8d1b9139beb31c6d5a6609e8.NginxMailingListRussian@forum.nginx.org> References: <428a8a2b8d1b9139beb31c6d5a6609e8.NginxMailingListRussian@forum.nginx.org> Message-ID: <20171117141857.GE26836@mdounin.ru> Hello! On Fri, Nov 17, 2017 at 07:50:30AM -0500, KycKyc wrote: > Здравствуйте, столкнулся со следующей проблемой. > Связка nginx + uwsgi, на продакшн сервере соединение с > upstream($upstream_connect_time) занимает 1 секунду (+-3ms), бывает раз в > 20-30 запросов проскакивает запрос с временем соединения в 0 сек, > промежуточных значений замечено небыло. > Запросы логируются только с 1го IP. > Upstream обслуживает http API. > > Статика отдается моментально. > Соединение с websocket upstream (тоже uwsgi) сервером занимает 0 секунд. > > Так же, в системном журнале никаких предупреждений нет. > > В чем может быть проблема ? > > nginx.conf: > https://pastebin.com/WipnHPkd > > Конфиг сервера: > https://pastebin.com/bfVCxP78 > > Текущий stub_status: > Active connections: 19993 > server accepts handled requests > 359071 359071 1362273 > Reading: 0 Writing: 10343 Waiting: 9639 > > > Для примера залогировал один запрос. > > Nginx debug log: > https://pastebin.com/sN30E6Ye > > tcpdump: > https://imgur.com/a/ntC4h Если верить дампу, то между установлением соединения прошло меньше 1 миллисекунды. Если верить логу - больше 1 секунды. При этом ip-адреса в дампе и в логе - не совпадают. Я тут вижу два варианта: - либо дамп не от того запроса, - либо дамп не полный и за секунду до этого был ещё один SYN-пакет, который почему-то в дамп не попал. Вообще, судя по описанным симптомам - проблему надо искать на стороне бэкенда, скорее всего он просто перегружен и не успевает отвечать на запросы. В результате первый SYN он просто игнорирует из-за переполнения очереди соединений (ибо Linux, и net.ipv4.tcp_abort_on_overflow по умолчанию 0), соединение устанавливается только после повторной отправки SYN'а - и вот она, 1 секунда задержки на любой коннект к перегруженному бэкенду. Так что рекомендация простая: смотреть внимательно на бэкенд, в частности - на его listen queue ("ss -nlt" в помощь). Ну и дальше решать проблему с загрузкой бэкенда. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Nov 17 15:05:41 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 17 Nov 2017 18:05:41 +0300 Subject: Kubernetes ingress In-Reply-To: References: Message-ID: <20171117150541.GG26836@mdounin.ru> Hello! On Fri, Nov 17, 2017 at 02:17:47PM +0200, Sargas wrote: > > по strace видно что процесс обслуживает соединения > > https://pastebin.com/N0Y4AANj > > И вообщем-то процессы завершаются через какое-то время. Но время не > > прогнозируемое. И в случае DEV окружения релоады nginx могут каждых 10 > > минут происходить. > > > > Хотелось бы понимать что еще покрутить можно. > > > > 8 ноября 2017 г., 14:45 пользователь Sargas написал: > > > > Приветствую! > >> > >> Использую ingress https://github.com/nginxinc/kubernetes-ingress , > >> возникла проблема с websocket'ами. После релоада nginx остаются висеть > >> воркеры > >> nginx 762 0.0 0.0 89284 11292 ? S Nov07 0:15 nginx: > >> worker process is shutting down > >> nginx 26321 0.0 0.0 88008 10196 ? S Nov07 0:18 nginx: > >> worker process is shutting down > >> > >> Разработчики добавили в сервис с nodejs отправку websocket ping-фреймов > >> для проверки работоспособности соединения, но воркеры всё равно могут > >> висеть от нескольких часов до суток. > >> Я добавил в конфиг worker_shutdown_timeout 1m; > >> http://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout > >> Я ожидал что через минуту все воркеры завершатся, но этого не происходит. Стоит посмотреть на патч тут, должно помочь: http://mailman.nginx.org/pipermail/nginx/2017-November/055130.html -- Maxim Dounin http://mdounin.ru/ From sargaskn на gmail.com Fri Nov 17 15:24:36 2017 From: sargaskn на gmail.com (Sargas) Date: Fri, 17 Nov 2017 17:24:36 +0200 Subject: Kubernetes ingress In-Reply-To: <20171117150541.GG26836@mdounin.ru> References: <20171117150541.GG26836@mdounin.ru> Message-ID: Благодарю! Проверю и отпишу по результатам. 17 ноября 2017 г., 17:05 пользователь Maxim Dounin написал: > Hello! > > On Fri, Nov 17, 2017 at 02:17:47PM +0200, Sargas wrote: > > > > по strace видно что процесс обслуживает соединения > > > https://pastebin.com/N0Y4AANj > > > И вообщем-то процессы завершаются через какое-то время. Но время не > > > прогнозируемое. И в случае DEV окружения релоады nginx могут каждых 10 > > > минут происходить. > > > > > > Хотелось бы понимать что еще покрутить можно. > > > > > > 8 ноября 2017 г., 14:45 пользователь Sargas > написал: > > > > > > Приветствую! > > >> > > >> Использую ingress https://github.com/nginxinc/kubernetes-ingress , > > >> возникла проблема с websocket'ами. После релоада nginx остаются висеть > > >> воркеры > > >> nginx 762 0.0 0.0 89284 11292 ? S Nov07 0:15 > nginx: > > >> worker process is shutting down > > >> nginx 26321 0.0 0.0 88008 10196 ? S Nov07 0:18 > nginx: > > >> worker process is shutting down > > >> > > >> Разработчики добавили в сервис с nodejs отправку websocket > ping-фреймов > > >> для проверки работоспособности соединения, но воркеры всё равно могут > > >> висеть от нескольких часов до суток. > > >> Я добавил в конфиг worker_shutdown_timeout 1m; > > >> http://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout > > >> Я ожидал что через минуту все воркеры завершатся, но этого не > происходит. > > Стоит посмотреть на патч тут, должно помочь: > > http://mailman.nginx.org/pipermail/nginx/2017-November/055130.html > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Nov 17 22:34:15 2017 From: nginx-forum на forum.nginx.org (cubespace) Date: Fri, 17 Nov 2017 17:34:15 -0500 Subject: =?UTF-8?B?0J3Rg9C20L3QsCDQv9C+0LzQvtGJ0Ywg0LIg0L3QsNGB0YLRgNC+0LnQutC1IG5n?= =?UTF-8?B?aW54?= Message-ID: Доброго времени суток. Есть небольшая проблема, пока что не получается ее решить. VPS Debian 9 Если зайти по адресу sait_com/engine/index.php то сайт откроется. А если по sait_com то будет 403 Forbidden. Вот конфиг: server { server_name sait.com www.sait.com; charset off; index index.html index.php; disable_symlinks if_not_owner from=$root_path; include /etc/nginx/vhosts-includes/*.conf; include /etc/nginx/vhosts-resources/sait.com/*.conf; access_log /var/www/httpd-logs/sait.com.access.log; error_log /var/www/httpd-logs/sait.com.error.log notice; ssi on; set $root_path /var/www/site/data/www/sait.com; root $root_path; listen 151.151.151.151:80; location / { location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @php; } } location @php { fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f webmaster на sait.com"; fastcgi_param SCRIPT_FILENAME /var/www/site/data/www/sait.com/engine/index.php; fastcgi_param HTTPS $http_x_forwarded_https if_not_empty; fastcgi_pass unix:/var/www/php-fpm/site.sock; try_files $uri =404; include /etc/nginx/fastcgi_params; } } И мне дали старые настройки на которых этот сайт работать но под другим доменом, а так как домен сменился то и перенести нужно на другой серв: server { listen 192.192.192.192:80; server_name www.mysite.net; root /home/www/mysite.net/static.www/; error_log /var/log/nginx/mysite.net-error.log warn; access_log /var/log/nginx/mysite.net-access.log detailed; location / { error_page 404 = @php; location ~ \. { expires 24h; } return 404; } location @php { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /home/www/mysite.net/engine/index.php; fastcgi_param HTTPS $http_x_forwarded_https if_not_empty; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; } } server { listen 192.192.192.192:80; server_name mysite.net; root /home/www/mysite.net/static/; error_log /var/log/nginx/mysite.net-error.log warn; access_log /var/log/nginx/mysite.net-access.log detailed; location = / { return 301 https://www.mysite.net/; } location / { add_header Cache-control public; add_header Access-Control-Allow-Origin https://www.mysite.net; expires 24h; error_page 404 = @php; log_not_found off; } location @php { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /home/www/mysite.net/engine/static.php; fastcgi_param HTTPS $http_x_forwarded_https if_not_empty; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; } } На старом mysite_net был SSL на новом не используют. Я вот пробовал менять настройки, но так не не получилось запустить на главном новом домене. Чтобы сайт открывался при sait_com. и если пробовать открыть через sait_com/engine/index.php то чтобы кидало на главную страницу sait_com. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277376,277376#msg-277376 From nginx-forum на forum.nginx.org Mon Nov 20 10:18:51 2017 From: nginx-forum на forum.nginx.org (KycKyc) Date: Mon, 20 Nov 2017 05:18:51 -0500 Subject: =?UTF-8?B?UmU6INCh0L7QtdC00LjQvdC10L3QuNC1INGBIFVwc3RyZWFtINC30LDQvdC40Lw=?= =?UTF-8?B?0LDQtdGCIDEg0YHQtdC60YPQvdC00YMu?= In-Reply-To: <20171117141857.GE26836@mdounin.ru> References: <20171117141857.GE26836@mdounin.ru> Message-ID: <09b256f1d269e1b7ef1c3f80a1649a95.NginxMailingListRussian@forum.nginx.org> Как вы правильно заметили, да IP другой, мы используем docker swarm и он выдает виртуальный IP своим сервисам. И как оказалось, проблема в этом самом VIP, если переключить сервисы на dnsrr, все работает замечательно. Даже тема есть похожая: https://forum.nginx.org/read.php?5,275243,275243 Тем не менее, спасибо за ответ, он помог мне обратить внимание на vip! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277361,277388#msg-277388 From coddoc на mail.ru Mon Nov 20 11:57:13 2017 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Mon, 20 Nov 2017 14:57:13 +0300 Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQutC4INGBINC+0YLQstC10YLQvtC8IDQwMA==?= Message-ID: <1511179033.874661767@f50.i.mail.ru> Доброго дня! Собственно, классическая секция server, принимающая запросы с неправильным $host: server {     listen :80 default_server;     listen :443 default_server;     server_name _;     return 444;     access_log .... здесь лог, что попадет в эту секцию } Формат этого лога: [$remote_addr] [$host] [$http_host] [$request] [$status] [$http_user_agent] [$server_name] [$server_port] Там такая запись: [155.94.254.143] [] [] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] [400] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80] В error логе вижу такое: [info] 7455#0: *356814 client prematurely closed connection while reading client request headers, client: 155.94.254.143, server: _, request: "GET /OWA-AUTODISCOVER-EWS HTTP/1.1", host: "" Хорошо, откуда 400, если должно быть 444? Пытаюсь эмулировать ситуацию: echo -e 'GET /OWA-AUTODISCOVER-EWS HTTP/1.1\n''host:\n''user-agent:Mozilla/5.0 Project 25499 (project25499.com)\n'| ncat 80 И получаю ожидаемое 444. Т.е. за исключением ответа 444 и моего IP, все аналогично: [<мой IP>] [] [] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] [444] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80] Вот такая печалька... Что я упускаю и как получить 400? Спасибо. -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 20 12:34:39 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2017 15:34:39 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSDQvtGC0LLQtdGC0L7QvCA0MDA=?= In-Reply-To: <1511179033.874661767@f50.i.mail.ru> References: <1511179033.874661767@f50.i.mail.ru> Message-ID: <20171120123439.GC62893@mdounin.ru> Hello! On Mon, Nov 20, 2017 at 02:57:13PM +0300, CoDDoC wrote: > Доброго дня! > > Собственно, классическая секция server, принимающая запросы с неправильным $host: > > server { >     listen :80 default_server; >     listen :443 default_server; >     server_name _; >     return 444; >     access_log .... здесь лог, что попадет в эту секцию > } > > Формат этого лога: > [$remote_addr] [$host] [$http_host] [$request] [$status] [$http_user_agent] [$server_name] [$server_port] > > Там такая запись: > [155.94.254.143] [] [] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] [400] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80] > > В error логе вижу такое: > [info] 7455#0: *356814 client prematurely closed connection while reading client request headers, client: 155.94.254.143, server: _, request: "GET /OWA-AUTODISCOVER-EWS HTTP/1.1", host: "" > > Хорошо, откуда 400, если должно быть 444? Если клиент закрыл соединение, не прислав запрос полностью - то это ошибка 400 Bad Request. До обработки запроса - которая вернула бы 444 в соответствии в "return 444" в конфигурации - дело просто не доходит, потому что запрос ещё не получен полностью. -- Maxim Dounin http://mdounin.ru/ From coddoc на mail.ru Mon Nov 20 12:43:16 2017 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Mon, 20 Nov 2017 15:43:16 +0300 Subject: =?UTF-8?B?UmVbMl06INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSDQvtGC0LLQtdGC0L7QvCA0MDA=?= In-Reply-To: <20171120123439.GC62893@mdounin.ru> References: <1511179033.874661767@f50.i.mail.ru> <20171120123439.GC62893@mdounin.ru> Message-ID: <1511181796.38168376@f329.i.mail.ru> Это я понял. Бот дернул запрос и быстро сбежал, чтобы не попасть в бан. Однако-же попал :) Как мне эмулировать такую ситуацию? >Понедельник, 20 ноября 2017, 15:34 +03:00 от Maxim Dounin : > >Hello! > >On Mon, Nov 20, 2017 at 02:57:13PM +0300, CoDDoC wrote: > >> Доброго дня! >> >> Собственно, классическая секция server, принимающая запросы с неправильным $host: >> >> server { >>     listen :80 default_server; >>     listen :443 default_server; >>     server_name _; >>     return 444; >>     access_log .... здесь лог, что попадет в эту секцию >> } >> >> Формат этого лога: >> [$remote_addr] [$host] [$http_host] [$request] [$status] [$http_user_agent] [$server_name] [$server_port] >> >> Там такая запись: >> [155.94.254.143] [] [] [GET /OWA-AUTODISCOVER-EWS HTTP/1.1] [400] [Mozilla/5.0 Project 25499 (project25499.com)] [_] [80] >> >> В error логе вижу такое: >> [info] 7455#0: *356814 client prematurely closed connection while reading client request headers, client: 155.94.254.143, server: _, request: "GET /OWA-AUTODISCOVER-EWS HTTP/1.1", host: "" >> >> Хорошо, откуда 400, если должно быть 444? > >Если клиент закрыл соединение, не прислав запрос полностью - то >это ошибка 400 Bad Request. До обработки запроса - которая >вернула бы 444 в соответствии в "return 444" в конфигурации - дело >просто не доходит, потому что запрос ещё не получен полностью. > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 20 13:24:10 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2017 16:24:10 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSDQvtGC0LLQtdGC0L7QvCA0MDA=?= In-Reply-To: <1511181796.38168376@f329.i.mail.ru> References: <1511179033.874661767@f50.i.mail.ru> <20171120123439.GC62893@mdounin.ru> <1511181796.38168376@f329.i.mail.ru> Message-ID: <20171120132410.GF62893@mdounin.ru> Hello! On Mon, Nov 20, 2017 at 03:43:16PM +0300, CoDDoC wrote: > Это я понял. Бот дернул запрос и быстро сбежал, чтобы не попасть в бан. Однако-же попал :) > Как мне эмулировать такую ситуацию? Я, вроде бы, вполне однозначно написал: > > Если клиент закрыл соединение, не прислав запрос полностью - > > то ... Так и эмулировать - закрывать соединение, не прислав запрос полностью. [...] -- Maxim Dounin http://mdounin.ru/ From coddoc на mail.ru Mon Nov 20 13:43:05 2017 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Mon, 20 Nov 2017 16:43:05 +0300 Subject: =?UTF-8?B?UmVbMl06INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSDQvtGC0LLQtdGC0L7QvCA0MDA=?= In-Reply-To: <20171120132410.GF62893@mdounin.ru> References: <1511179033.874661767@f50.i.mail.ru> <1511181796.38168376@f329.i.mail.ru> <20171120132410.GF62893@mdounin.ru> Message-ID: <1511185385.805128152@f392.i.mail.ru> Ладно, с этим разберусь. Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server для обработки запроса. Я слегка запутался, что от чего зависит: $host от $server_name или наоборот? Вот как я это понимаю. 1. Сначала неправильный запрос: echo -e 'HEAD http://www.other-domain.com/some-path HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 Как все происходит (ИМХО): 1.1. Получаем значение $host из строки запроса: $host = www.other-domain.com На заголовок ($http_host = www.my-domain.com) в данном случае не смотрим. 1.2. Ищем секцию, соответствующую значению $host для заданного порта (80) 1.3. Такой секции не существует, запрос передается в дефолтовую, и получаем $server_name = _ ---------------------------------------------------- 2. Теперь правильный запрос: echo -e 'HEAD / HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 2.1. В строке запроса хоста нет, берем из заголовка ($http_host = www.my-domain.com). Получаем значение $host из $http_host: $host= www.my-domain.com 2.2. Ищем секцию, соответствующую значению $host для заданного порта (80) 2.3. Передаем в нее запрос и получаем $server_name = www.my-domain.com ---------------------------------------------------- 3. Опять неправильный запрос с пустым $http_host: echo -e 'HEAD / HTTP/1.1\n''host:\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 3.1. Значения $host = '' и $http_host = '' 3.2. Ищем секцию, соответствующую значению $host для заданного порта (80) 3.3. Такой секции не существует, запрос передается в дефолтовую, и получаем $server_name = _ 3.4. $host получает значение $server_name, т.е. $host = _ Т.е., в отличие от примера 2, не $server_name получаем из $host, а $host из $server_name Я верно понимаю алгоритм? >Понедельник, 20 ноября 2017, 16:24 +03:00 от Maxim Dounin : > >Hello! > >On Mon, Nov 20, 2017 at 03:43:16PM +0300, CoDDoC wrote: > >> Это я понял. Бот дернул запрос и быстро сбежал, чтобы не попасть в бан. Однако-же попал :) >> Как мне эмулировать такую ситуацию? > >Я, вроде бы, вполне однозначно написал: > >> > Если клиент закрыл соединение, не прислав запрос полностью - >> > то ... > >Так и эмулировать - закрывать соединение, не прислав запрос >полностью. > >[...] > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Mon Nov 20 13:55:17 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 20 Nov 2017 16:55:17 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQndC10L/QvtC90Y/RgtC60Lgg0YEg0L7RgtCy0LXRgtC+0Lwg?= =?UTF-8?B?NDAw?= In-Reply-To: <1511185385.805128152@f392.i.mail.ru> References: <1511179033.874661767@f50.i.mail.ru> <1511181796.38168376@f329.i.mail.ru> <20171120132410.GF62893@mdounin.ru> <1511185385.805128152@f392.i.mail.ru> Message-ID: <20171120135517.GA5355@zxy.spb.ru> On Mon, Nov 20, 2017 at 04:43:05PM +0300, CoDDoC wrote: > Ладно, с этим разберусь. > Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server для обработки запроса. > > Я слегка запутался, что от чего зависит: $host от $server_name или наоборот? > Вот как я это понимаю. > > 1. Сначала неправильный запрос: > echo -e 'HEAD http://www.other-domain.com/some-path HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 > Как все происходит (ИМХО): > 1.1. Получаем значение $host из строки запроса: $host = www.other-domain.com > На заголовок ($http_host = www.my-domain.com) в данном случае не смотрим. так может делать только прокся (причем прямая, а не реверсивная), для www-сервера это некорректный запрос. отвечать 500 или 400, секция нафиг. From mdounin на mdounin.ru Mon Nov 20 14:24:49 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2017 17:24:49 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSDQvtGC0LLQtdGC0L7QvCA0MDA=?= In-Reply-To: <1511185385.805128152@f392.i.mail.ru> References: <1511179033.874661767@f50.i.mail.ru> <1511181796.38168376@f329.i.mail.ru> <20171120132410.GF62893@mdounin.ru> <1511185385.805128152@f392.i.mail.ru> Message-ID: <20171120142449.GH62893@mdounin.ru> Hello! On Mon, Nov 20, 2017 at 04:43:05PM +0300, CoDDoC wrote: > Ладно, с этим разберусь. > Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server для обработки запроса. > > Я слегка запутался, что от чего зависит: $host от $server_name или наоборот? > Вот как я это понимаю. > > 1. Сначала неправильный запрос: > echo -e 'HEAD http://www.other-domain.com/some-path HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 > Как все происходит (ИМХО): > 1.1. Получаем значение $host из строки запроса: $host = www.other-domain.com > На заголовок ($http_host = www.my-domain.com) в данном случае не смотрим. > 1.2. Ищем секцию, соответствующую значению $host для заданного порта (80) > 1.3. Такой секции не существует, запрос передается в дефолтовую, и получаем $server_name = _ > > ---------------------------------------------------- > 2. Теперь правильный запрос: > echo -e 'HEAD / HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 > 2.1. В строке запроса хоста нет, берем из заголовка ($http_host = www.my-domain.com). > Получаем значение $host из $http_host: $host= www.my-domain.com > 2.2. Ищем секцию, соответствующую значению $host для заданного порта (80) > 2.3. Передаем в нее запрос и получаем $server_name = www.my-domain.com > > ---------------------------------------------------- > 3. Опять неправильный запрос с пустым $http_host: > echo -e 'HEAD / HTTP/1.1\n''host:\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 > 3.1. Значения $host = '' и $http_host = '' > 3.2. Ищем секцию, соответствующую значению $host для заданного порта (80) > 3.3. Такой секции не существует, запрос передается в дефолтовую, и получаем $server_name = _ > 3.4. $host получает значение $server_name, т.е. $host = _ > Т.е., в отличие от примера 2, не $server_name получаем из $host, а $host из $server_name > > Я верно понимаю алгоритм? Да, как-то так. Если в строке запроса используется полный адрес, то $host берётся оттуда. Иначе - из заголовка Host. Если заголовок Host отсутствует или пустой - будет использовано имя сервера, которое также доступно в переменной $server_name. Документация тут: http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_host http://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name -- Maxim Dounin http://mdounin.ru/ From sargaskn на gmail.com Mon Nov 20 14:28:04 2017 From: sargaskn на gmail.com (Sargas) Date: Mon, 20 Nov 2017 16:28:04 +0200 Subject: Kubernetes ingress In-Reply-To: References: <20171117150541.GG26836@mdounin.ru> Message-ID: Патч не помог, проверял со свежей версией nginx. Больше 10-ти минут воркеры находятся в nginx: worker process is shutting down # nginx -V nginx version: nginx/1.13.6 built by gcc 6.3.0 20170516 (Debian 6.3.0-18) built with OpenSSL 1.1.0f 25 May 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/tmp/tmp.kzg1MIPOeG/nginx-1.13.6/nginx-1.13.6=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' 17 ноября 2017 г., 17:24 пользователь Sargas написал: > Благодарю! > > Проверю и отпишу по результатам. > > 17 ноября 2017 г., 17:05 пользователь Maxim Dounin > написал: > > Hello! >> >> On Fri, Nov 17, 2017 at 02:17:47PM +0200, Sargas wrote: >> >> > > по strace видно что процесс обслуживает соединения >> > > https://pastebin.com/N0Y4AANj >> > > И вообщем-то процессы завершаются через какое-то время. Но время не >> > > прогнозируемое. И в случае DEV окружения релоады nginx могут каждых 10 >> > > минут происходить. >> > > >> > > Хотелось бы понимать что еще покрутить можно. >> > > >> > > 8 ноября 2017 г., 14:45 пользователь Sargas >> написал: >> > > >> > > Приветствую! >> > >> >> > >> Использую ingress https://github.com/nginxinc/kubernetes-ingress , >> > >> возникла проблема с websocket'ами. После релоада nginx остаются >> висеть >> > >> воркеры >> > >> nginx 762 0.0 0.0 89284 11292 ? S Nov07 0:15 >> nginx: >> > >> worker process is shutting down >> > >> nginx 26321 0.0 0.0 88008 10196 ? S Nov07 0:18 >> nginx: >> > >> worker process is shutting down >> > >> >> > >> Разработчики добавили в сервис с nodejs отправку websocket >> ping-фреймов >> > >> для проверки работоспособности соединения, но воркеры всё равно могут >> > >> висеть от нескольких часов до суток. >> > >> Я добавил в конфиг worker_shutdown_timeout 1m; >> > >> http://nginx.org/ru/docs/ngx_core_module.html#worker_shutdow >> n_timeout >> > >> Я ожидал что через минуту все воркеры завершатся, но этого не >> происходит. >> >> Стоит посмотреть на патч тут, должно помочь: >> >> http://mailman.nginx.org/pipermail/nginx/2017-November/055130.html >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 20 14:31:02 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2017 17:31:02 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQndC10L/QvtC90Y/RgtC60Lgg0YEg0L7RgtCy0LXRgtC+0Lwg?= =?UTF-8?B?NDAw?= In-Reply-To: <20171120135517.GA5355@zxy.spb.ru> References: <1511179033.874661767@f50.i.mail.ru> <1511181796.38168376@f329.i.mail.ru> <20171120132410.GF62893@mdounin.ru> <1511185385.805128152@f392.i.mail.ru> <20171120135517.GA5355@zxy.spb.ru> Message-ID: <20171120143102.GI62893@mdounin.ru> Hello! On Mon, Nov 20, 2017 at 04:55:17PM +0300, Slawa Olhovchenkov wrote: > On Mon, Nov 20, 2017 at 04:43:05PM +0300, CoDDoC wrote: > > > Ладно, с этим разберусь. > > Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server для обработки запроса. > > > > Я слегка запутался, что от чего зависит: $host от $server_name или наоборот? > > Вот как я это понимаю. > > > > 1. Сначала неправильный запрос: > > echo -e 'HEAD http://www.other-domain.com/some-path HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 > > Как все происходит (ИМХО): > > 1.1. Получаем значение $host из строки запроса: $host = www.other-domain.com > > На заголовок ($http_host = www.my-domain.com) в данном случае не смотрим. > > так может делать только прокся (причем прямая, а не реверсивная), для www-сервера это некорректный > запрос. отвечать 500 или 400, секция нафиг. Не совсем так. Цитата из RFC 2616, https://tools.ietf.org/html/rfc2616#section-5.1.2: To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. Тот же текст в RFC 7230 - в секции 5.3.2. -- Maxim Dounin http://mdounin.ru/ From coddoc на mail.ru Mon Nov 20 14:46:35 2017 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Mon, 20 Nov 2017 17:46:35 +0300 Subject: =?UTF-8?B?UmVbMl06INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSDQvtGC0LLQtdGC0L7QvCA0MDA=?= In-Reply-To: <20171120142449.GH62893@mdounin.ru> References: <1511179033.874661767@f50.i.mail.ru> <1511185385.805128152@f392.i.mail.ru> <20171120142449.GH62893@mdounin.ru> Message-ID: <1511189195.499130196@f479.i.mail.ru> Вот в той документации-то я как-раз и запутался. Спасибо. Вопросов нет. >Понедельник, 20 ноября 2017, 17:24 +03:00 от Maxim Dounin : > >Hello! > >On Mon, Nov 20, 2017 at 04:43:05PM +0300, CoDDoC wrote: > >> Ладно, с этим разберусь. >> Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server для обработки запроса. >> >> Я слегка запутался, что от чего зависит: $host от $server_name или наоборот? >> Вот как я это понимаю. >> >> 1. Сначала неправильный запрос: >> echo -e 'HEAD http://www.other-domain.com/some-path HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 >> Как все происходит (ИМХО): >> 1.1. Получаем значение $host из строки запроса: $host = www.other-domain.com >> На заголовок ($http_host = www.my-domain.com ) в данном случае не смотрим. >> 1.2. Ищем секцию, соответствующую значению $host для заданного порта (80) >> 1.3. Такой секции не существует, запрос передается в дефолтовую, и получаем $server_name = _ >> >> ---------------------------------------------------- >> 2. Теперь правильный запрос: >> echo -e 'HEAD / HTTP/1.1\n''host:www.my-domain.com\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 >> 2.1. В строке запроса хоста нет, берем из заголовка ($http_host = www.my-domain.com ). >> Получаем значение $host из $http_host: $host= www.my-domain.com >> 2.2. Ищем секцию, соответствующую значению $host для заданного порта (80) >> 2.3. Передаем в нее запрос и получаем $server_name = www.my-domain.com >> >> ---------------------------------------------------- >> 3. Опять неправильный запрос с пустым $http_host: >> echo -e 'HEAD / HTTP/1.1\n''host:\n''user-agent:NCAT-TEST\n'| ncat www.my-domain.com 80 >> 3.1. Значения $host = '' и $http_host = '' >> 3.2. Ищем секцию, соответствующую значению $host для заданного порта (80) >> 3.3. Такой секции не существует, запрос передается в дефолтовую, и получаем $server_name = _ >> 3.4. $host получает значение $server_name, т.е. $host = _ >> Т.е., в отличие от примера 2, не $server_name получаем из $host, а $host из $server_name >> >> Я верно понимаю алгоритм? > >Да, как-то так. Если в строке запроса используется полный адрес, >то $host берётся оттуда. Иначе - из заголовка Host. Если >заголовок Host отсутствует или пустой - будет использовано имя >сервера, которое также доступно в переменной $server_name. > >Документация тут: > >http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_host >http://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 20 17:03:22 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2017 20:03:22 +0300 Subject: Kubernetes ingress In-Reply-To: References: <20171117150541.GG26836@mdounin.ru> Message-ID: <20171120170321.GJ62893@mdounin.ru> Hello! On Mon, Nov 20, 2017 at 04:28:04PM +0200, Sargas wrote: > Патч не помог, проверял со свежей версией nginx. Больше 10-ти минут воркеры > находятся в nginx: worker process is shutting down > > # nginx -V > nginx version: nginx/1.13.6 [...] Патч-то наложить не забыли? На всякий случае: в 1.3.6 патча нет, нужно именно накладывать руками и пересобирать nginx. Если речь именно про websocket'ы, то он должен был помочь. Впрочем, в любом случае сейчас уже закоммичен чуть более лучший патч, который заодно лечит аналогичную проблему в mail и улучшает ситуацию в stream, тут: http://hg.nginx.org/nginx/rev/9c29644f6d03 Релиз с ним (1.3.7) будет завтра. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Nov 20 18:25:38 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Nov 2017 21:25:38 +0300 Subject: Kubernetes ingress In-Reply-To: <20171120170321.GJ62893@mdounin.ru> References: <20171117150541.GG26836@mdounin.ru> <20171120170321.GJ62893@mdounin.ru> Message-ID: <20171120182538.GK62893@mdounin.ru> Hello! On Mon, Nov 20, 2017 at 08:03:22PM +0300, Maxim Dounin wrote: > Hello! > > On Mon, Nov 20, 2017 at 04:28:04PM +0200, Sargas wrote: > > > Патч не помог, проверял со свежей версией nginx. Больше 10-ти минут воркеры > > находятся в nginx: worker process is shutting down > > > > # nginx -V > > nginx version: nginx/1.13.6 > > [...] > > Патч-то наложить не забыли? На всякий случае: в 1.3.6 патча нет, > нужно именно накладывать руками и пересобирать nginx. Если речь > именно про websocket'ы, то он должен был помочь. > > Впрочем, в любом случае сейчас уже закоммичен чуть более лучший > патч, который заодно лечит аналогичную проблему в mail и улучшает > ситуацию в stream, тут: > > http://hg.nginx.org/nginx/rev/9c29644f6d03 > > Релиз с ним (1.3.7) будет завтра. Err, 1.13.6 и 1.13.7 соответственно, конечно же. -- Maxim Dounin http://mdounin.ru/ From sargaskn на gmail.com Mon Nov 20 20:15:00 2017 From: sargaskn на gmail.com (Sargas) Date: Mon, 20 Nov 2017 22:15:00 +0200 Subject: Kubernetes ingress In-Reply-To: <20171120182538.GK62893@mdounin.ru> References: <20171117150541.GG26836@mdounin.ru> <20171120170321.GJ62893@mdounin.ru> <20171120182538.GK62893@mdounin.ru> Message-ID: >Патч-то наложить не забыли? На всякий случае: в 1.3.6 патча нет, нужно именно накладывать руками и пересобирать nginx. Если речь именно про websocket'ы, то он должен был помочь. Не забыл. Я взял ваш докер образ https://github.com/nginxinc/docker-nginx/blob/3ba04e37d8f9ed7709fd30bf4dc6c36554e578ac/mainline/stretch/Dockerfile , сделал чтобы для amd64 тоже с исходников собирался nginx, добавил туда наложение патча перед компиляцией. После чего собрал контейнер с ingress'ом использую контейнер с патченым nginx'ом. Завтра днем перепроверю конечно. И заодно попробую с 1.13.7 Благодарю! 20 ноября 2017 г., 20:25 пользователь Maxim Dounin написал: > Hello! > > On Mon, Nov 20, 2017 at 08:03:22PM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Mon, Nov 20, 2017 at 04:28:04PM +0200, Sargas wrote: > > > > > Патч не помог, проверял со свежей версией nginx. Больше 10-ти минут > воркеры > > > находятся в nginx: worker process is shutting down > > > > > > # nginx -V > > > nginx version: nginx/1.13.6 > > > > [...] > > > > Патч-то наложить не забыли? На всякий случае: в 1.3.6 патча нет, > > нужно именно накладывать руками и пересобирать nginx. Если речь > > именно про websocket'ы, то он должен был помочь. > > > > Впрочем, в любом случае сейчас уже закоммичен чуть более лучший > > патч, который заодно лечит аналогичную проблему в mail и улучшает > > ситуацию в stream, тут: > > > > http://hg.nginx.org/nginx/rev/9c29644f6d03 > > > > Релиз с ним (1.3.7) будет завтра. > > Err, 1.13.6 и 1.13.7 соответственно, конечно же. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sargaskn на gmail.com Tue Nov 21 09:21:52 2017 From: sargaskn на gmail.com (Sargas) Date: Tue, 21 Nov 2017 11:21:52 +0200 Subject: Kubernetes ingress In-Reply-To: References: <20171117150541.GG26836@mdounin.ru> <20171120170321.GJ62893@mdounin.ru> <20171120182538.GK62893@mdounin.ru> Message-ID: Проверил с патчем http://hg.nginx.org/nginx/rev/9c29644f6d03 - всё работает как нужно. Через минуту старые воркеры завершают свою работу. Спасибо Максим! 20 ноября 2017 г., 22:15 пользователь Sargas написал: > >Патч-то наложить не забыли? На всякий случае: в 1.3.6 патча нет, нужно > именно накладывать руками и пересобирать nginx. Если речь именно про > websocket'ы, то он должен был помочь. > Не забыл. Я взял ваш докер образ https://github.com/nginxinc/ > docker-nginx/blob/3ba04e37d8f9ed7709fd30bf4dc6c3 > 6554e578ac/mainline/stretch/Dockerfile , сделал чтобы для amd64 тоже с > исходников собирался nginx, добавил туда наложение патча перед компиляцией. > После чего собрал контейнер с ingress'ом использую контейнер с патченым > nginx'ом. > > Завтра днем перепроверю конечно. И заодно попробую с 1.13.7 > Благодарю! > > 20 ноября 2017 г., 20:25 пользователь Maxim Dounin > написал: > > Hello! >> >> On Mon, Nov 20, 2017 at 08:03:22PM +0300, Maxim Dounin wrote: >> >> > Hello! >> > >> > On Mon, Nov 20, 2017 at 04:28:04PM +0200, Sargas wrote: >> > >> > > Патч не помог, проверял со свежей версией nginx. Больше 10-ти минут >> воркеры >> > > находятся в nginx: worker process is shutting down >> > > >> > > # nginx -V >> > > nginx version: nginx/1.13.6 >> > >> > [...] >> > >> > Патч-то наложить не забыли? На всякий случае: в 1.3.6 патча нет, >> > нужно именно накладывать руками и пересобирать nginx. Если речь >> > именно про websocket'ы, то он должен был помочь. >> > >> > Впрочем, в любом случае сейчас уже закоммичен чуть более лучший >> > патч, который заодно лечит аналогичную проблему в mail и улучшает >> > ситуацию в stream, тут: >> > >> > http://hg.nginx.org/nginx/rev/9c29644f6d03 >> > >> > Релиз с ним (1.3.7) будет завтра. >> >> Err, 1.13.6 и 1.13.7 соответственно, конечно же. >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Nov 21 10:11:54 2017 From: nginx-forum на forum.nginx.org (bodomic) Date: Tue, 21 Nov 2017 05:11:54 -0500 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgNCw0LfQvtCx0YDQsNGC0YzRgdGPINGBIHByb3h5?= =?UTF-8?B?IHBhc3MgdXJpIGRlY29kZQ==?= Message-ID: <5a0475a1e13ec7f9838d5b422eadf39f.NginxMailingListRussian@forum.nginx.org> Уже, кажется, все идеи перепробовал, ничего не помогает. Попробую максимально точно описать проблему: На вход фронтенда приходит урл с encoded символами, среди которых есть %20. На proxy_pass этот %20 обращается обратно в пробел и всё ломается. В простейшей конфигурации имеем: Nginx: location ~ ^/api(.*) { proxy_pass http://backend/api.php?q=$1; } Apache (backend): "GET /api.php?q=blabla1 blabla2"... Ну и в логе ошибка "/api.php?q=blabla1 не валидный запрос без blabla2". Я уже бессчётное количестко подходов сделал к экранированию и переписыванию переменных, нужен divine intervention, который скажет, как правильно, видимо. nginx version: nginx/1.10.2 built with OpenSSL 1.0.1f 6 Jan 2014 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --add-module=/build/nginx-1.10.2/debian/modules/headers-more-nginx-module --add-module=/build/nginx-1.10.2/debian/modules/nginx-auth-pam --add-module=/build/nginx-1.10.2/debian/modules/nginx-cache-purge --add-module=/build/nginx-1.10.2/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-1.10.2/debian/modules/nginx-development-kit --add-module=/build/nginx-1.10.2/debian/modules/nginx-echo --add-module=/build/nginx-1.10.2/debian/modules/ngx-fancyindex --add-module=/build/nginx-1.10.2/debian/modules/nginx-http-push --add-module=/build/nginx-1.10.2/debian/modules/nginx-lua --add-module=/build/nginx-1.10.2/debian/modules/nginx-upload-progress --add-module=/build/nginx-1.10.2/debian/modules/nginx-upstream-fair --add-module=/build/nginx-1.10.2/debian/modules/ngx_http_substitutions_filter_module --add-module=/build/nginx-1.10.2/debian/modules/nginx_http_upstream_check_module --add-module=/build/nginx-1.10.2/debian/modules/graphite-nginx-module --add-module=/build/nginx-1.10.2/debian/modules/nginx-module-vts --add-module=/build/nginx-1.10.2/debian/modules/nginx-fluentd-module Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277422,277422#msg-277422 From nginx-forum на forum.nginx.org Tue Nov 21 12:04:51 2017 From: nginx-forum на forum.nginx.org (vitcool) Date: Tue, 21 Nov 2017 07:04:51 -0500 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YDQsNC30L7QsdGA0LDRgtGM0YHRjyDRgSBw?= =?UTF-8?B?cm94eSBwYXNzIHVyaSBkZWNvZGU=?= In-Reply-To: <5a0475a1e13ec7f9838d5b422eadf39f.NginxMailingListRussian@forum.nginx.org> References: <5a0475a1e13ec7f9838d5b422eadf39f.NginxMailingListRussian@forum.nginx.org> Message-ID: <453dc2d0d8882950e77f9342173fb4bd.NginxMailingListRussian@forum.nginx.org> bodomic Wrote: ------------------------------------------------------- > Уже, кажется, все идеи перепробовал, ничего не помогает. > Попробую максимально точно описать проблему: На вход фронтенда > приходит урл с encoded символами, среди которых есть %20. На > proxy_pass этот %20 обращается обратно в пробел и всё ломается. в аналогичной ситуации, я устал искать решение и стал передавать через заголовки, благо был доступ и к фронту и к бекенду я про proxy_set_header Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277422,277424#msg-277424 From mdounin на mdounin.ru Tue Nov 21 13:18:32 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Nov 2017 16:18:32 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YDQsNC30L7QsdGA0LDRgtGM0YHRjyDRgSBw?= =?UTF-8?B?cm94eSBwYXNzIHVyaSBkZWNvZGU=?= In-Reply-To: <5a0475a1e13ec7f9838d5b422eadf39f.NginxMailingListRussian@forum.nginx.org> References: <5a0475a1e13ec7f9838d5b422eadf39f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20171121131831.GN62893@mdounin.ru> Hello! On Tue, Nov 21, 2017 at 05:11:54AM -0500, bodomic wrote: > Уже, кажется, все идеи перепробовал, ничего не помогает. > Попробую максимально точно описать проблему: На вход фронтенда приходит урл > с encoded символами, среди которых есть %20. На proxy_pass этот %20 > обращается обратно в пробел и всё ломается. > В простейшей конфигурации имеем: > Nginx: > > location ~ ^/api(.*) { > proxy_pass http://backend/api.php?q=$1; > } > > Apache (backend): > "GET /api.php?q=blabla1 blabla2"... > > > Ну и в логе ошибка "/api.php?q=blabla1 не валидный запрос без blabla2". > Я уже бессчётное количестко подходов сделал к экранированию и переписыванию > переменных, нужен divine intervention, который скажет, как правильно, > видимо. Проблема в том, что location работает с раскодированным URI запроса (и соответственно в $1 попадает раскодированная часть URI), а proxy_pass с переменными ожидает полностью сформированный и правильно закодированный URI, как например в конструкции proxy_pass http://127.0.0.1$request_uri; Для задачи "поменять URI запроса на /api.php?q=..." проще всего использовать rewrite, благо он умеет правильно кодировать URI при его изменении. Как-то так должно заработать (untested): location /api/ { rewrite ^/api(/.*) /api.php?q=$1? break; proxy_pass http://backend; } -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Nov 21 15:26:24 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Nov 2017 18:26:24 +0300 Subject: nginx-1.13.7 Message-ID: <20171121152623.GS62893@mdounin.ru> Изменения в nginx 1.13.7 21.11.2017 *) Исправление: в переменной $upstream_status. *) Исправление: в рабочем процессе мог произойти segmentation fault, если бэкенд возвращал ответ "101 Switching Protocols" на подзапрос. *) Исправление: если при переконфигурации изменялся размер зоны разделяемой памяти и переконфигурация завершалась неудачно, то в главном процессе происходил segmentation fault. *) Исправление: в модуле ngx_http_fastcgi_module. *) Исправление: nginx возвращал ошибку 500, если в директиве xslt_stylesheet были заданы параметры без использования переменных. *) Изменение: при использовании варианта библиотеки zlib от Intel в лог писались сообщения "gzip filter failed to use preallocated memory". *) Исправление: директива worker_shutdown_timeout не работала при использовании почтового прокси-сервера и при проксировании WebSocket-соединений. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Nov 21 15:33:42 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 21 Nov 2017 10:33:42 -0500 Subject: gzip filter failed to use preallocated memory In-Reply-To: <20171115191655.GA26836@mdounin.ru> References: <20171115191655.GA26836@mdounin.ru> Message-ID: <56cfc143a3ae437004ae905a2bf26147.NginxMailingListRussian@forum.nginx.org> > Возможно. Я отправил его коллегам на review, если возражений не > будет - закоммичу. Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276955,277433#msg-277433 From nginx-forum на forum.nginx.org Tue Nov 21 17:18:41 2017 From: nginx-forum на forum.nginx.org (vitcool) Date: Tue, 21 Nov 2017 12:18:41 -0500 Subject: nginx-1.13.7 In-Reply-To: <20171121152623.GS62893@mdounin.ru> References: <20171121152623.GS62893@mdounin.ru> Message-ID: <7feee9e7623002098e8e8c6d127156f3.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Изменения в nginx 1.13.7 > 21.11.2017 > *) Исправление: nginx возвращал ошибку 500, если в директиве > xslt_stylesheet были заданы параметры без использования > переменных. Я прошу прощения, а nginx умеет делать xsl трансформацию? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277432,277435#msg-277435 From mdounin на mdounin.ru Tue Nov 21 17:23:48 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Nov 2017 20:23:48 +0300 Subject: nginx-1.13.7 In-Reply-To: <7feee9e7623002098e8e8c6d127156f3.NginxMailingListRussian@forum.nginx.org> References: <20171121152623.GS62893@mdounin.ru> <7feee9e7623002098e8e8c6d127156f3.NginxMailingListRussian@forum.nginx.org> Message-ID: <20171121172348.GU62893@mdounin.ru> Hello! On Tue, Nov 21, 2017 at 12:18:41PM -0500, vitcool wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Изменения в nginx 1.13.7 > > 21.11.2017 > > *) Исправление: nginx возвращал ошибку 500, если в директиве > > xslt_stylesheet были заданы параметры без использования > > переменных. > > > Я прошу прощения, а nginx умеет делать xsl трансформацию? Да, начиная с 0.7.8. Подробнее тут: http://nginx.org/ru/docs/http/ngx_http_xslt_module.html -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Nov 21 20:46:58 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 21 Nov 2017 22:46:58 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. Message-ID: Здравствуйте, All! nginx установлен из официального репозитория nginx.org, CentOS 7.4 В логах вот такое наблюдается при перезапуске nginx 1.13.6: systemd: Starting nginx - high performance web server... nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument systemd: Started nginx - high performance web server. И вот такое при запуске nginx 1.13.7: systemd: Starting nginx - high performance web server... systemd: PID file /var/run/nginx.pid not readable (yet?) after start. systemd: Started nginx - high performance web server. Как это можно победить, чтобы в логах такого не было? Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804 И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993 Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл? Обе эти ошибки возникают в systemd функции service_load_pid_file() https://github.com/systemd/systemd/blob/master/src/core/service.c#L815 Когда systemd не может прочитать pid-файл. Насколько я понял из комментариев в функции service_enter_start() https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909 /* For forking services we wait until the start * process exited. */ И в функции service_sigchld_event(): https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959 /* Forking services may occasionally move to a new PID. * As long as they update the PID file before exiting the old * PID, they're fine. */ Systemd считает что сервис запустился после того как start process exited ? А у nginx получается так, что start process exited, а pid файл еще не создан и это создает проблемы systemd? Можно ли как-то исправить поведение nginx, чтобы systemd не флудил в логи сообщениями об ошибках? -- Best regards, Gena From sargaskn на gmail.com Tue Nov 21 22:33:59 2017 From: sargaskn на gmail.com (Sargas) Date: Wed, 22 Nov 2017 00:33:59 +0200 Subject: nginx-1.13.7 In-Reply-To: <20171121172348.GU62893@mdounin.ru> References: <20171121152623.GS62893@mdounin.ru> <7feee9e7623002098e8e8c6d127156f3.NginxMailingListRussian@forum.nginx.org> <20171121172348.GU62893@mdounin.ru> Message-ID: А можете прокомментировать чуть подробнее про? >Исправление: в переменной $upstream_status. >Исправление: в модуле ngx_http_fastcgi_module. Благодарю! 21 ноября 2017 г., 19:23 пользователь Maxim Dounin написал: > Hello! > > On Tue, Nov 21, 2017 at 12:18:41PM -0500, vitcool wrote: > > > Maxim Dounin Wrote: > > ------------------------------------------------------- > > > Изменения в nginx 1.13.7 > > > 21.11.2017 > > > *) Исправление: nginx возвращал ошибку 500, если в директиве > > > xslt_stylesheet были заданы параметры без использования > > > переменных. > > > > > > Я прошу прощения, а nginx умеет делать xsl трансформацию? > > Да, начиная с 0.7.8. > Подробнее тут: > > http://nginx.org/ru/docs/http/ngx_http_xslt_module.html > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Nov 22 00:12:09 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 22 Nov 2017 03:12:09 +0300 Subject: nginx-1.13.7 In-Reply-To: References: <20171121152623.GS62893@mdounin.ru> <7feee9e7623002098e8e8c6d127156f3.NginxMailingListRussian@forum.nginx.org> <20171121172348.GU62893@mdounin.ru> Message-ID: <20171122001209.GW62893@mdounin.ru> Hello! On Wed, Nov 22, 2017 at 12:33:59AM +0200, Sargas wrote: > А можете прокомментировать чуть подробнее про? > >Исправление: в переменной $upstream_status. Если в конфигурации было сказано "proxy_next_upstream http_503 http_504", то в переменной $upstream_status вместо статуса 503 / 504 отображался статус 502. Подробнее тут: http://hg.nginx.org/nginx/rev/882ad033d43c > >Исправление: в модуле ngx_http_fastcgi_module. Не сохранялась позиция парсинга заголовков FastCGI records, и если вдруг при получении заголовков ответа какой-то record header приходил частично (что на практике, судя по всему, не встречается, но теоретически возможно) - то парсинг ломался, и возникала ошибка. Подробнее тут: http://hg.nginx.org/nginx/rev/3b635e8fd499 -- Maxim Dounin http://mdounin.ru/ From thresh на nginx.com Wed Nov 22 10:01:32 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Wed, 22 Nov 2017 13:01:32 +0300 Subject: nginx repos Ubuntu 17.10 artful In-Reply-To: <4c3a5b30-a6bc-0378-6118-2a0747f906bd@nginx.com> References: <4c3a5b30-a6bc-0378-6118-2a0747f906bd@nginx.com> Message-ID: On 10/11/2017 14:13, Konstantin Pavlov wrote: > Добрый день, > > On 10/11/2017 10:14, Vadim Lazovskiy wrote: >> Здравствуйте. >> >> Не могли бы вы приготовить пакеты для Ubuntu 17.10? >> >> Спасибо! > > Будет со следующим mainline релизом. Пакеты для 17.10 выложены для 1.13.7. -- Konstantin Pavlov www.nginx.com From thresh на nginx.com Wed Nov 22 10:06:31 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Wed, 22 Nov 2017 13:06:31 +0300 Subject: ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf In-Reply-To: <7440c153-18ca-f4ec-520c-173bd29244fa@nginx.com> References: <55338a5f-8564-a1f6-2aa6-d0697fec3bac@csdoc.com> <7440c153-18ca-f4ec-520c-173bd29244fa@nginx.com> Message-ID: On 10/11/2017 17:37, Konstantin Pavlov wrote: >> В юнит-файле CentOS 7 эта строчка >> >> ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf >> >> выглядит совершенно лишней и не нужной, она только создает проблемы. >> >> Может быть имеет смысл вообще убрать строку >> >> ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf >> >> из юнит-файла? Хуже от этого ведь не станет, только лучше. >> >> Или я ошибаюсь и в этой строчке есть какой-смысл? Какой? > Не ошибаетесь. Убрал, начиная с 1.13.7: http://hg.nginx.org/pkg-oss/rev/3074685a0155 -- Konstantin Pavlov www.nginx.com From vadim.lazovskiy на gmail.com Wed Nov 22 11:05:27 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Wed, 22 Nov 2017 14:05:27 +0300 Subject: nginx repos Ubuntu 17.10 artful In-Reply-To: References: <4c3a5b30-a6bc-0378-6118-2a0747f906bd@nginx.com> Message-ID: Большое спасибо! 22 ноября 2017 г., 13:01 пользователь Konstantin Pavlov написал: > On 10/11/2017 14:13, Konstantin Pavlov wrote: > > Добрый день, > > > > On 10/11/2017 10:14, Vadim Lazovskiy wrote: > >> Здравствуйте. > >> > >> Не могли бы вы приготовить пакеты для Ubuntu 17.10? > >> > >> Спасибо! > > > > Будет со следующим mainline релизом. > > Пакеты для 17.10 выложены для 1.13.7. > > -- > Konstantin Pavlov > www.nginx.com > -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Wed Nov 22 17:43:14 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 22 Nov 2017 20:43:14 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: References: Message-ID: <20171122174314.GC78325@mdounin.ru> Hello! On Tue, Nov 21, 2017 at 10:46:58PM +0200, Gena Makhomed wrote: > Здравствуйте, All! > > nginx установлен из официального репозитория nginx.org, CentOS 7.4 > > В логах вот такое наблюдается при перезапуске nginx 1.13.6: > > systemd: Starting nginx - high performance web server... > nginx: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok > nginx: nginx: configuration file /etc/nginx/nginx.conf test is successful > systemd: Failed to read PID from file /var/run/nginx.pid: Invalid argument > systemd: Started nginx - high performance web server. > > И вот такое при запуске nginx 1.13.7: > > systemd: Starting nginx - high performance web server... > systemd: PID file /var/run/nginx.pid not readable (yet?) after start. > systemd: Started nginx - high performance web server. > > Как это можно победить, чтобы в логах такого не было? > > Рекомендуют вот такой workaround: https://stackoverflow.com/a/42084804 > И еще вот такое нашлось заодно: https://stackoverflow.com/a/42555993 > > Но это наверное неправильно будет, добавлять sleep 0.1 в юнит-файл? > > Обе эти ошибки возникают в systemd функции service_load_pid_file() > https://github.com/systemd/systemd/blob/master/src/core/service.c#L815 > Когда systemd не может прочитать pid-файл. > > Насколько я понял из комментариев в функции service_enter_start() > https://github.com/systemd/systemd/blob/master/src/core/service.c#L1909 > > /* For forking services we wait until the start > * process exited. */ > > И в функции service_sigchld_event(): > https://github.com/systemd/systemd/blob/master/src/core/service.c#L2959 > > /* Forking services may occasionally move to a new PID. > * As long as they update the PID file before exiting the old > * PID, they're fine. */ > > Systemd считает что сервис запустился > после того как start process exited ? > > А у nginx получается так, что start process exited, > а pid файл еще не создан и это создает проблемы systemd? > > Можно ли как-то исправить поведение nginx, > чтобы systemd не флудил в логи сообщениями об ошибках? С точки зрения абстрактного счастья для всех даром - наверное, поведение systemd логично, и на момент выхода запущенного процесса pid-файл должен уже существовать. С точки зрения практики - паттерн "daemon(); write_pidfile();" используется чуть менее, чем везде, вплоть до соответствующих библиотечных функций. Так что инициатива выглядит, скажем так, сомнительной. Проще всего, IMHO, это было бы заткнуть на уровне systemd, дожидаясь появления pid-файла при необходимости. -- Maxim Dounin http://mdounin.ru/ From scratch на virgilsecurity.com Thu Nov 23 09:51:49 2017 From: scratch на virgilsecurity.com (Alexey Ermishkin) Date: Thu, 23 Nov 2017 14:51:49 +0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzRiyDQv9GA0Lgg0L3QsNC/0LjRgdCw0L3QuNC4INC80L4=?= =?UTF-8?B?0LTRg9C70Y8t0LfQsNC80LXQvdGLIFRMUyDQtNC70Y8gTkdJTlggKE5vaXNl?= =?UTF-8?B?U29ja2V0KQ==?= Message-ID: <007201d36440$b066ad80$11340880$@virgilsecurity.com> Приветствую, меня зовут Алексей. Я работаю в компании VirgilSecurity и являюсь разработчиком протокола NoiseSocket (noisesocket.com). Так же наша компания занимается разработкой модуля для NGINX, реализующего протокол NoiseSocket. Я хотел бы описать цели, результаты и узнать мнение о решениях и спросить совета о других путях решения задачи. Протокол NoiseSocket позиционируется как более простая в реализации и быстрая альтернатива TLS. Одной из его главных фич является возможность установки безопасного соединения без использования сертификатов, используя лишь "сырые" приватные\публичные ключи. Это необходимо для IoT, бекендов, p2p и многих других задач. Основной целью создания модуля для NGINX - это обеспечение функциональности reverse proxy и load balancing, где соединение между прокси-сервером и backend серверами осуществляется по протоколу NoiseSocket. Второй целью является возможность принимать входящие соединения по протоколу NoiseSocket, то есть обеспечивать поддержку протокола на стороне backend с помощью NGINX. Для обеспечения нужного функционала модуль должен обеспечить: 1 При создании соединения на стороне noise client инициировать и отработать handshake phase по алгоритму noise initiator. 2 При входящем соединении на стороне noise server ответить на входящие handshake сообщения и отработать handshake phase по алгоритму noise . 3 После успешного завершения handshake phase упаковывать/распаковывать сетевой траффик в NoiseSocket transport messages. Сначала была рассмотрена возможность создания модуля для контекста http, однако здесь траффик для сторонних модулей предоставляется в виде составляющих http, что не дает возможности для работы протокола, имеющего более низкий уровень, чем http. Затем был рассмотрен вариант для контекста stream. Однако предоставляемый функционал для сторонних модулей здесь оказался весьма ограничен. Здесь для работы протокола уровня представления есть возможность только на стороне noise server, когда появляется входящее соединение и можно прицепить модуль к одной из фаз обработки входящего запроса. На стороне noise client такой возможности нет, потому что здесь имеется функционал только для custom load balancing. Мы можем добавить свой обработчик: ngx_stream_session_t->peer.get(ngx_peer_connection_t *pc,void *data); Однако его вызов осуществляется до создания соединения: В файле ngx_event_connect.c: ngx_int_t ngx_event_connect_peer(ngx_peer_connection_t *pc) { :. rc = pc->get(pc, pc->data); :. c = ngx_get_connection(s, pc->log); : } Таким образом нет никакой возможности инициировать процедуру handshake и назначить свои обработчики recv, send, recv_chain, send_chain для обработки траффика средствами стороннего модуля. В итоге было принято решение создать модуль, реализующий собственный контекст по обработке траффика. За основу был взят код контекста stream, где был убран TLS, и добавлен NoiseSocket. Для обработки траффика только по протоколу NoiseSocket приемлема следующая конфигурация, которая наиболее оптимальна по быстродействию: https://i.imgur.com/fucb9J0.png В итоге для сохранения существующего функционала NGINX по обработке http контента определена следующая конфигурация: https://i.imgur.com/6vnOdwd.png или https://i.imgur.com/WpMhdKh.png Так как подобная конфигурация не оптимальна в плане быстродействия, то хотелось бы узнать о более перспективных вариантах внедрения протокола уровня представления для NGINX в качестве модуля. Рабочий вариант спецификации для NoiseSocket: http://noisesocket.com/spec/noisesocket/ Репозиторий с кодом модуля https://github.com/VirgilSecurity/virgil-NGINX-noise-socket From gmm на csdoc.com Thu Nov 23 13:49:43 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 23 Nov 2017 15:49:43 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171122174314.GC78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> Message-ID: On 22.11.2017 19:43, Maxim Dounin wrote: >> systemd: PID file /var/run/nginx.pid not readable (yet?) after start. >> Можно ли как-то исправить поведение nginx, >> чтобы systemd не флудил в логи сообщениями об ошибках? > С точки зрения абстрактного счастья для всех даром - наверное, > поведение systemd логично, и на момент выхода запущенного процесса > pid-файл должен уже существовать. > > С точки зрения практики - паттерн "daemon(); write_pidfile();" > используется чуть менее, чем везде, вплоть до соответствующих > библиотечных функций. Так что инициатива выглядит, скажем так, > сомнительной. Спросил об этом в списке рассылки systemd-devel: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039812.html Идея переписать systemd там энтузиазма не вызвала: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039820.html Более того, мне прислали ссылку на официальную документацию systemd: Many other deficiencies with the BSD daemon() function are documented in systemd's daemon(7) manpage. В systemd's daemon(7) manpage очень подробно расписано как должны вести себя SysV Daemons при работе с systemd. И очевидно, что nginx этим требованиям не соответствует. Original process должен вызывать exit() только после того, как будет полностью завершена инициализация daemon process, в частности, после того как daemon process создаст свой pid файл. > Проще всего, IMHO, это было бы заткнуть на уровне systemd, > дожидаясь появления pid-файла при необходимости. Кстати, дожидаться pid-файла - это не совсем тривиальная задача, ведь nginx пишет свой pid-файл не атомарно. Может же быть так, что файл уже появился, но он будет нулевого размера и попытка прочитать из него pid завершится ошибкой? Или он будет частично записан и тогда из pid-файла прочитается pid другого процесса? Можно ли будет исправить поведение nginx чтобы он соответствовал требованиям к SysV Daemons из systemd's daemon(7) manpage? Поведение systemd изменить не получится, я уже пробовал. -- Best regards, Gena From mdounin на mdounin.ru Thu Nov 23 15:37:54 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 23 Nov 2017 18:37:54 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: References: <20171122174314.GC78325@mdounin.ru> Message-ID: <20171123153754.GE78325@mdounin.ru> Hello! On Thu, Nov 23, 2017 at 03:49:43PM +0200, Gena Makhomed wrote: > On 22.11.2017 19:43, Maxim Dounin wrote: > > >> systemd: PID file /var/run/nginx.pid not readable (yet?) after start. > > >> Можно ли как-то исправить поведение nginx, > >> чтобы systemd не флудил в логи сообщениями об ошибках? > > > С точки зрения абстрактного счастья для всех даром - наверное, > > поведение systemd логично, и на момент выхода запущенного процесса > > pid-файл должен уже существовать. > > > > С точки зрения практики - паттерн "daemon(); write_pidfile();" > > используется чуть менее, чем везде, вплоть до соответствующих > > библиотечных функций. Так что инициатива выглядит, скажем так, > > сомнительной. > > Спросил об этом в списке рассылки systemd-devel: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039812.html > > Идея переписать systemd там энтузиазма не вызвала: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039820.html > > Более того, мне прислали ссылку на официальную документацию systemd: > > Many other deficiencies with the BSD daemon() function > are documented in systemd's daemon(7) manpage. > > В systemd's daemon(7) manpage очень подробно расписано > как должны вести себя SysV Daemons при работе с systemd. > И очевидно, что nginx этим требованиям не соответствует. > > Original process должен вызывать exit() только после того, > как будет полностью завершена инициализация daemon process, > в частности, после того как daemon process создаст свой pid файл. Это, что называется, всё очень интересно, но вызывает сомнение успех подобных рекомендаций. Особенно с учётом отсутствия каких-либо внятных примеров того, что же использовать вместо daemon(3). О чём я, собственно, и писал выше. Впрочем, если верить ответу тут: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html то соответствующее сообщение можно смело игнорировать, и systemd на самом деле умеет дожидаться создания pid-файла. То есть вопрос лишь в том, что при этом systemd пишет в лог. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Nov 23 16:28:55 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 23 Nov 2017 18:28:55 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171123153754.GE78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> Message-ID: <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> On 23.11.2017 17:37, Maxim Dounin wrote: >> В systemd's daemon(7) manpage очень подробно расписано >> как должны вести себя SysV Daemons при работе с systemd. >> И очевидно, что nginx этим требованиям не соответствует. >> Original process должен вызывать exit() только после того, >> как будет полностью завершена инициализация daemon process, >> в частности, после того как daemon process создаст свой pid файл. > Это, что называется, всё очень интересно, но вызывает сомнение > успех подобных рекомендаций. Особенно с учётом отсутствия > каких-либо внятных примеров того, что же использовать вместо > daemon(3). О чём я, собственно, и писал выше. Что использовать вместо daemon(3) документировано в daemon(7): https://www.freedesktop.org/software/systemd/man/daemon.html Lennart Poettering очень подробно ответил на этот вопрос в рассылке: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html Впрочем, если очень хочется использовать все-таки daemon(3) то можно: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html > Впрочем, если верить ответу тут: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html > то соответствующее сообщение можно смело игнорировать, и systemd > на самом деле умеет дожидаться создания pid-файла. То есть вопрос > лишь в том, что при этом systemd пишет в лог. Не надо верить тому, что говорит Michael Chapman - он ошибается. systemd не ждет появления pid-файла, я это проверял по исходникам. Лучше верить тому, что говорит Lennart Poettering, автор systemd: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html Всегда надо указывать корректный PIDFile= для сервисов Type=forking: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html Максим, можно ли сделать так, чтобы nginx соответствовал тем требованиям которые предъявляет systemd к SysV Daemons? https://www.freedesktop.org/software/systemd/man/daemon.html -- Best regards, Gena From igor на sysoev.ru Thu Nov 23 16:44:57 2017 From: igor на sysoev.ru (Igor Sysoev) Date: Thu, 23 Nov 2017 19:44:57 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> Message-ID: <8874E9E0-2249-4736-A3D4-0FAA021AEA27@sysoev.ru> > On 23 Nov 2017, at 19:28, Gena Makhomed wrote: > > Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html Интересно, откуда он это придумал про двойной fork()? Во FreeBSD используется только один fork() что в 2017 году: https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025&view=co что в 1994: https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573&view=co -- Igor Sysoev http://nginx.com From mdounin на mdounin.ru Thu Nov 23 17:13:06 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 23 Nov 2017 20:13:06 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> Message-ID: <20171123171306.GH78325@mdounin.ru> Hello! On Thu, Nov 23, 2017 at 06:28:55PM +0200, Gena Makhomed wrote: > On 23.11.2017 17:37, Maxim Dounin wrote: > > >> В systemd's daemon(7) manpage очень подробно расписано > >> как должны вести себя SysV Daemons при работе с systemd. > >> И очевидно, что nginx этим требованиям не соответствует. > > >> Original process должен вызывать exit() только после того, > >> как будет полностью завершена инициализация daemon process, > >> в частности, после того как daemon process создаст свой pid файл. > > > Это, что называется, всё очень интересно, но вызывает сомнение > > успех подобных рекомендаций. Особенно с учётом отсутствия > > каких-либо внятных примеров того, что же использовать вместо > > daemon(3). О чём я, собственно, и писал выше. > > Что использовать вместо daemon(3) документировано в daemon(7): > https://www.freedesktop.org/software/systemd/man/daemon.html > > Lennart Poettering очень подробно ответил на этот вопрос в рассылке: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html > > Впрочем, если очень хочется использовать все-таки daemon(3) то можно: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html > > Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html Это всё замечательно (за вычетом того, предлагаемое использование daemon(3) почему-то не учитывает, что после вызова daemon(3) parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет того, что чуть менее, чем все существующие демоны делают именно "daemon(); write_pidfile();", и при таком подходе - ситуацию не изменить. > > Впрочем, если верить ответу тут: > > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html > > > то соответствующее сообщение можно смело игнорировать, и systemd > > на самом деле умеет дожидаться создания pid-файла. То есть вопрос > > лишь в том, что при этом systemd пишет в лог. > > Не надо верить тому, что говорит Michael Chapman - он ошибается. > systemd не ждет появления pid-файла, я это проверял по исходникам. > > Лучше верить тому, что говорит Lennart Poettering, автор systemd: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html > > Всегда надо указывать корректный PIDFile= для сервисов Type=forking: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html > > Максим, можно ли сделать так, чтобы nginx соответствовал > тем требованиям которые предъявляет systemd к SysV Daemons? > > https://www.freedesktop.org/software/systemd/man/daemon.html Можно, я ж разве против? -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Nov 23 17:16:56 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 23 Nov 2017 20:16:56 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <8874E9E0-2249-4736-A3D4-0FAA021AEA27@sysoev.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <8874E9E0-2249-4736-A3D4-0FAA021AEA27@sysoev.ru> Message-ID: <20171123171656.GI78325@mdounin.ru> Hello! On Thu, Nov 23, 2017 at 07:44:57PM +0300, Igor Sysoev wrote: > > On 23 Nov 2017, at 19:28, Gena Makhomed wrote: > > > > Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: > > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html > > Интересно, откуда он это придумал про двойной fork()? > > Во FreeBSD используется только один fork() что в 2017 году: > https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025&view=co > что в 1994: > https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573&view=co Двойной форк нужен на Линуксе, чтобы случайно не получить себе обратно controlling terminal. Документировано, например, тут в man daemon(3) у glibc, http://man7.org/linux/man-pages/man3/daemon.3.html: The GNU C library implementation of this function was taken from BSD, and does not employ the double-fork technique (i.e., fork(2), setsid(2), fork(2)) that is necessary to ensure that the resulting daemon process is not a session leader. Instead, the resulting daemon is a session leader. On systems that follow System V semantics (e.g., Linux), this means that if the daemon opens a terminal that is not already a controlling terminal for another session, then that terminal will inadvertently become the controlling terminal for the daemon. Смысла это делать в nginx'е - скорее нет, IMHO. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Nov 23 17:30:45 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 23 Nov 2017 12:30:45 -0500 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171122174314.GC78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> Message-ID: > С точки зрения практики - паттерн "daemon(); write_pidfile();" > используется чуть менее, чем везде, вплоть до соответствующих > библиотечных функций. Так что инициатива выглядит, скажем так, > сомнительной. > > Проще всего, IMHO, это было бы заткнуть на уровне systemd, > дожидаясь появления pid-файла при необходимости. Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать pid файл, вместо Type=fork использовать Type=notify, это более гибкий вариант сообщить Systemd что процесс готов к работе. Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него. https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277438,277473#msg-277473 From gmm на csdoc.com Thu Nov 23 17:31:47 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 23 Nov 2017 19:31:47 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <8874E9E0-2249-4736-A3D4-0FAA021AEA27@sysoev.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <8874E9E0-2249-4736-A3D4-0FAA021AEA27@sysoev.ru> Message-ID: On 23.11.2017 18:44, Igor Sysoev wrote: >> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html > Интересно, откуда он это придумал про двойной fork()? Скорее всего из книжки Richard W. Stevens Advanced Programming in the UNIX Environment, 3rd Edition https://www.amazon.com/Advanced-Programming-UNIX-Environment-3rd/dp/0321637739 Подробный ответ на stackoverflow с объяснением зачем двойной форк: https://stackoverflow.com/a/31485256 Кстати, сама эта книжка Advanced Programming in the UNIX Environment, 3rd Edition в PDF формате на английском доступна для скачивания в интернете: http://www.codeman.net/wp-content/uploads/2014/04/APUE-3rd.pdf https://github.com/shihyu/Linux_Programming/blob/master/books/Advanced.Programming.in.the.UNIX.Environment.3rd.Edition.0321637739.pdf -- Best regards, Gena From gmm на csdoc.com Thu Nov 23 17:53:59 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 23 Nov 2017 19:53:59 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: References: <20171122174314.GC78325@mdounin.ru> Message-ID: On 23.11.2017 19:30, S.A.N wrote: > для Systemd лучше вообще не указывать pid файл Не лучше. Если Type=forking то pid файл необходимо указывать всегда: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html > вместо Type=fork использовать Type=notify, это более гибкий вариант > сообщить Systemd что процесс готов к работе. Тогда не будет работать обновление исполняемого файла на лету: http://nginx.org/ru/docs/control.html#upgrade # service nginx upgrade Starting new master nginx: [ OK ] Graceful shutdown of old nginx: [ OK ] -- Best regards, Gena From mdounin на mdounin.ru Thu Nov 23 17:55:37 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 23 Nov 2017 20:55:37 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: References: <20171122174314.GC78325@mdounin.ru> Message-ID: <20171123175537.GK78325@mdounin.ru> Hello! On Thu, Nov 23, 2017 at 12:30:45PM -0500, S.A.N wrote: > > С точки зрения практики - паттерн "daemon(); write_pidfile();" > > используется чуть менее, чем везде, вплоть до соответствующих > > библиотечных функций. Так что инициатива выглядит, скажем так, > > сомнительной. > > > > Проще всего, IMHO, это было бы заткнуть на уровне systemd, > > дожидаясь появления pid-файла при необходимости. > > Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать pid > файл, вместо Type=fork использовать Type=notify, это более гибкий вариант > сообщить Systemd что процесс готов к работе. > > Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него. > https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= Нет, спасибо, собираться с systemd'шными библиотеками - это не к нам. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Thu Nov 23 18:30:30 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 23 Nov 2017 23:30:30 +0500 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171123175537.GK78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123175537.GK78325@mdounin.ru> Message-ID: 23 ноября 2017 г., 22:55 пользователь Maxim Dounin написал: > Hello! > > On Thu, Nov 23, 2017 at 12:30:45PM -0500, S.A.N wrote: > > > > С точки зрения практики - паттерн "daemon(); write_pidfile();" > > > используется чуть менее, чем везде, вплоть до соответствующих > > > библиотечных функций. Так что инициатива выглядит, скажем так, > > > сомнительной. > > > > > > Проще всего, IMHO, это было бы заткнуть на уровне systemd, > > > дожидаясь появления pid-файла при необходимости. > > > > Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать > pid > > файл, вместо Type=fork использовать Type=notify, это более гибкий вариант > > сообщить Systemd что процесс готов к работе. > > > > Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него. > > https://www.freedesktop.org/software/systemd/man/systemd. > service.html#Type= > > Нет, спасибо, собираться с systemd'шными библиотеками - это не к > нам. > > не совсем про systemd, скорее про пакеты не пробовали вот такие хуки https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd ? (для pre, post скриптов) > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Nov 23 19:00:07 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 23 Nov 2017 21:00:07 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171123171306.GH78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> Message-ID: On 23.11.2017 19:13, Maxim Dounin wrote: >>>> В systemd's daemon(7) manpage очень подробно расписано >>>> как должны вести себя SysV Daemons при работе с systemd. >>>> И очевидно, что nginx этим требованиям не соответствует. >>>> Original process должен вызывать exit() только после того, >>>> как будет полностью завершена инициализация daemon process, >>>> в частности, после того как daemon process создаст свой pid файл. >>> Это, что называется, всё очень интересно, но вызывает сомнение >>> успех подобных рекомендаций. Особенно с учётом отсутствия >>> каких-либо внятных примеров того, что же использовать вместо >>> daemon(3). О чём я, собственно, и писал выше. >> Что использовать вместо daemon(3) документировано в daemon(7): >> https://www.freedesktop.org/software/systemd/man/daemon.html >> Lennart Poettering очень подробно ответил на этот вопрос в рассылке: >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html >> Впрочем, если очень хочется использовать все-таки daemon(3) то можно: >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html >> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html > Это всё замечательно (за вычетом того, предлагаемое использование > daemon(3) почему-то не учитывает, что после вызова daemon(3) > parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет > того, что чуть менее, чем все существующие демоны делают именно > "daemon(); write_pidfile();", и при таком подходе - ситуацию не > изменить. А при каком подходе ситуацию c nginx изменить можно? Если говорить конструктивно. Посмотрел у себя в системе, CentOS 7.4 - там достаточно мало осталось сервисов Type=forking. Postfix например, запускает много процессов, как и nginx - проверил его исходники, он действует точно так, как рекомендуется в документе systemd's daemon(7) manpage. О каких именно "чуть менее, чем все существующие демоны" сервисах Вы говорите? Есть еще кроме nginx примеры некорректного поведения systemd-сервисов с Type=forking которые запускают много дочерних процессов как это делает nginx или postfix? Проблемы в работе под управлением systemd сейчас есть только у nginx: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. Все остальные сервисы у меня на серверах под systemd работают нормально. Когда я спросил у Lennart Poettering насчет того, что все существующие демоны так делают он мне ответил "the better written ones synchronize properly". Хочется чтобы и nginx тоже попадал в эту категорию "better written". Когда я спрашивал разработчиков systemd чтобы они исправили systemd, вот что Lennart Poettering из Red Hat мне ответил: https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html [...] >>> But "daemon(); write_pidfile();" is common pattern >>> used by many services and even in library functions. >> It may be common, but not necessarily correct. The parent process should >> only exit *after* finishing all the preparations (i.e. something like >> "fork(); write_pidfile(); exit()"), since systemd uses the exit as a signal >> that the daemon is now "ready". > You are joking? Why you think that this pattern is not correct? It doesn't work on SysV init either: "/etc/init.d/nginx start ; /etc/init.d/nginx stop" is racy as it will leave ngnx running if it the PID file isn't written by the time the stop command is used. [...] > Or may be it will be simpler to fix root cause of problem in systemd? Well, I wish you good luck fixing SysV init scripts too. Before we talk about "fixing systemd", let's talk how do you intend to make "/etc/init.d/nginx start ; /etc/init.d/nginx stop" work correctly, without races, without sometimes leaving nginx running, if you don't wait for the PID file to be written safely before exiting. Lennart -- Lennart Poettering, Red Hat ================================================================= Что ему ответить? Как сделать так, чтобы команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" работала без глюков на CentOS 6 ? Она ведь глючит. Может быть действительно имеет смысл сделать "wait for the PID file to be written safely before exiting" и не брать для nginx пример с кривых и глючных демонов у которых есть race conditions при старте/остановке? >> Максим, можно ли сделать так, чтобы nginx соответствовал >> тем требованиям которые предъявляет systemd к SysV Daemons? >> https://www.freedesktop.org/software/systemd/man/daemon.html > Можно, я ж разве против? А как это лучше всего сделать? -- Best regards, Gena From bgx на protva.ru Thu Nov 23 19:04:43 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 23 Nov 2017 22:04:43 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171122174314.GC78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> Message-ID: <20171123190443.t3wgjhq7ibppp52y@protva.ru> On Wed, Nov 22, 2017 at 08:43:14PM +0300, Maxim Dounin wrote: > С точки зрения практики - паттерн "daemon(); write_pidfile();" > используется чуть менее, чем везде, вплоть до соответствующих > библиотечных функций. Так что инициатива выглядит, скажем так, > сомнительной. Отговорка, скажем так, неубедительная. Есть масса рискованных и ненадёжных паттернов поведения, но зачем им следовать, если можно сделать всё правильно, и это достаточно просто? Например, возможен такой вариант: 1. Папа выполняет pipe(2) и форкает дочку. 2. Дочка читает конфиги, открывает сокеты и делает все нужные предварительные проверки, если всё ок -- пишет в пайп свой pid и закрывает пайп, если нет -- делает exit(). 3. Прочитав пайп, папа видит смотрит, вернулся ли pid или eof/ошибка. Если прочитан правильный pid, то он записывается в файл, и папа делает exit(0), если нет, то дочка подбирается waitpid()ом и её статус выбрасывается через exit() наверх. В идеале можно (и я бы сказал нужно) перед чтением пайпа поставить на него select() с таймером, чтобы задать максимальное время на запуск подпроцесса. > Проще всего, IMHO, это было бы заткнуть на уровне systemd, > дожидаясь появления pid-файла при необходимости. Лучше делать не "как проще", а правильно. -- Eugene Berdnikov From thresh на nginx.com Thu Nov 23 20:06:30 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 23 Nov 2017 23:06:30 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: References: <20171122174314.GC78325@mdounin.ru> <20171123175537.GK78325@mdounin.ru> Message-ID: <7f4caa83-cbc9-b6b8-f978-e741bf4185d2@nginx.com> Здравствуйте, Илья, On 23/11/2017 21:30, Илья Шипицин wrote: > не совсем про systemd, скорее про пакеты > > не пробовали вот такие хуки https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd ? > (для pre, post скриптов) Мы собираем пакеты не только под systemd-enabled дистрибутивы из одних и тех же исходных пакетов, поэтому использовали уже раскрытые версии в соответствущих местах (см. http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l238). -- Konstantin Pavlov www.nginx.com From mdounin на mdounin.ru Thu Nov 23 21:00:58 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Nov 2017 00:00:58 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> Message-ID: <20171123210058.GM78325@mdounin.ru> Hello! On Thu, Nov 23, 2017 at 09:00:07PM +0200, Gena Makhomed wrote: > On 23.11.2017 19:13, Maxim Dounin wrote: > > >>>> В systemd's daemon(7) manpage очень подробно расписано > >>>> как должны вести себя SysV Daemons при работе с systemd. > >>>> И очевидно, что nginx этим требованиям не соответствует. > > >>>> Original process должен вызывать exit() только после того, > >>>> как будет полностью завершена инициализация daemon process, > >>>> в частности, после того как daemon process создаст свой pid файл. > > >>> Это, что называется, всё очень интересно, но вызывает сомнение > >>> успех подобных рекомендаций. Особенно с учётом отсутствия > >>> каких-либо внятных примеров того, что же использовать вместо > >>> daemon(3). О чём я, собственно, и писал выше. > > >> Что использовать вместо daemon(3) документировано в daemon(7): > >> https://www.freedesktop.org/software/systemd/man/daemon.html > > >> Lennart Poettering очень подробно ответил на этот вопрос в рассылке: > >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html > > >> Впрочем, если очень хочется использовать все-таки daemon(3) то можно: > >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html > > >> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: > >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html > > > Это всё замечательно (за вычетом того, предлагаемое использование > > daemon(3) почему-то не учитывает, что после вызова daemon(3) > > parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет > > того, что чуть менее, чем все существующие демоны делают именно > > "daemon(); write_pidfile();", и при таком подходе - ситуацию не > > изменить. > > А при каком подходе ситуацию c nginx изменить можно? > Если говорить конструктивно. Чтобы изменить ситуацию конкретно с nginx - нужно сесть и сделать хороший патч. Очевидно, это сделать можно, и даже не очень сложно. Я, как уже неоднократно сказал, не возражаю. Но сама идея, что все должны сесть и заняться выпиливанием стандартного паттерна, который работал десятки лет, и делать вместо это что-то своё с синхронизацией - не взлетит. > Посмотрел у себя в системе, CentOS 7.4 - там достаточно мало осталось > сервисов Type=forking. Postfix например, запускает много процессов, > как и nginx - проверил его исходники, он действует точно так, > как рекомендуется в документе systemd's daemon(7) manpage. > > О каких именно "чуть менее, чем все существующие демоны" > сервисах Вы говорите? Есть еще кроме nginx примеры некорректного > поведения systemd-сервисов с Type=forking которые запускают много > дочерних процессов как это делает nginx или postfix? Не вижу причин, почему демоны с "много дочерних процессов" должны отличаться от сервисов с "мало дочерних процессов". In no particular order, - memcached, делает deamonize() (который суть daemon(3) и завершает исходный процесс), после чего пишет pid-файл. https://github.com/memcached/memcached/blob/master/memcached.c#L6788 https://github.com/memcached/memcached/blob/master/memcached.c#L6924 - httpd, делает apr_proc_detach() (который суть daemon(3) и тоже завершает исходный процесс) в worker_pre_config(), и сильно после пишет pid-файл (в worker_run()). https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c#L2002 https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c#L1663 - Reference-реализация PEP 3143 - Standard daemon process library, https://www.python.org/dev/peps/pep-3143/, зовётся функция detach_process_context() (которая в свою очередь зовёт функцию с говорящим названием fork_then_exit_parent()), потом пишется pid-файл. https://pagure.io/python-daemon/blob/master/f/daemon/daemon.py#_376 https://pagure.io/python-daemon/blob/master/f/daemon/daemon.py#_389 - nptd, в отсутствии опции --wait-sync (которая суть замена ntpdate) выходит сразу после fork(), pid-файл пишется позже в рамках getconfig(). https://github.com/ntp-project/ntp/blob/stable/ntpd/ntpd.c#L730 https://github.com/ntp-project/ntp/blob/stable/ntpd/ntpd.c#L892 Тысячи их. [...] -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Nov 23 23:12:46 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 24 Nov 2017 01:12:46 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171123210058.GM78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> Message-ID: <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> On 23.11.2017 23:00, Maxim Dounin wrote: >>> Это всё замечательно (за вычетом того, предлагаемое использование >>> daemon(3) почему-то не учитывает, что после вызова daemon(3) >>> parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет >>> того, что чуть менее, чем все существующие демоны делают именно >>> "daemon(); write_pidfile();", и при таком подходе - ситуацию не >>> изменить. >> А при каком подходе ситуацию c nginx изменить можно? >> Если говорить конструктивно. > Чтобы изменить ситуацию конкретно с nginx - нужно сесть и сделать > хороший патч. Очевидно, это сделать можно, и даже не очень > сложно. Я, как уже неоднократно сказал, не возражаю. Для меня это будет слишком сложный патч, в разумные сроки не напишу. > Но сама идея, что все должны сесть и заняться выпиливанием > стандартного паттерна, который работал десятки лет, и делать > вместо это что-то своё с синхронизацией - не взлетит. Эта идея уже взлетела. Если демон состоит из одного процесса - systemd может однозначно узнать его pid, проблемы могут возникать только с теми демонами, которые состоят из нескольких процессов. Из известных мне сервисов состоящих из более чем одного процесса: * postfix - сделали синхронизацию и проблем с systemd больше нет. * httpd - перевели на Type=notify и проблем с systemd больше нет. * php-fpm - перевели на Type=notify и проблем с systemd больше нет. * nginx - только с этим сервисом наблюдаются проблемы под systemd. >> О каких именно "чуть менее, чем все существующие демоны" >> сервисах Вы говорите? Есть еще кроме nginx примеры некорректного >> поведения systemd-сервисов с Type=forking которые запускают много >> дочерних процессов как это делает nginx или postfix? > Не вижу причин, почему демоны с "много дочерних процессов" должны > отличаться от сервисов с "мало дочерних процессов". systemd однозначно определяет pid демонов состоящих из одного процесса и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile= - все будет работать как надо даже если они стартуют без синхронизации. Вот что говорит Lennart Poettering из Red Hat: If you use Type=forking, then you'll get away with not specifiying a PID file in most cases, but it's racy as soon as you have more than one daemon process, and nginx appears to be one of this kind, hence please specify PIDFile=. https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html -- Best regards, Gena From mdounin на mdounin.ru Fri Nov 24 04:12:31 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Nov 2017 07:12:31 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> Message-ID: <20171124041231.GN78325@mdounin.ru> Hello! On Fri, Nov 24, 2017 at 01:12:46AM +0200, Gena Makhomed wrote: > On 23.11.2017 23:00, Maxim Dounin wrote: > > >>> Это всё замечательно (за вычетом того, предлагаемое использование > >>> daemon(3) почему-то не учитывает, что после вызова daemon(3) > >>> parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет > >>> того, что чуть менее, чем все существующие демоны делают именно > >>> "daemon(); write_pidfile();", и при таком подходе - ситуацию не > >>> изменить. > > >> А при каком подходе ситуацию c nginx изменить можно? > >> Если говорить конструктивно. > > > Чтобы изменить ситуацию конкретно с nginx - нужно сесть и сделать > > хороший патч. Очевидно, это сделать можно, и даже не очень > > сложно. Я, как уже неоднократно сказал, не возражаю. > > Для меня это будет слишком сложный патч, в разумные сроки не напишу. > > > Но сама идея, что все должны сесть и заняться выпиливанием > > стандартного паттерна, который работал десятки лет, и делать > > вместо это что-то своё с синхронизацией - не взлетит. > > Эта идея уже взлетела. Если демон состоит из одного процесса > - systemd может однозначно узнать его pid, проблемы могут возникать > только с теми демонами, которые состоят из нескольких процессов. > Из известных мне сервисов состоящих из более чем одного процесса: > > * postfix - сделали синхронизацию и проблем с systemd больше нет. > * httpd - перевели на Type=notify и проблем с systemd больше нет. > * php-fpm - перевели на Type=notify и проблем с systemd больше нет. > * nginx - только с этим сервисом наблюдаются проблемы под systemd. Давайте, всё-таки, опеределимся: мы за всё хорошее против всего плохого (== чтобы демоны писали pid-файлы до выхода запущенного процесса, потому что по другому - плохо), или вопрос исключительно в том, чтобы systemd не ругался в логи? Если за всё хорошее - то проблема, очевидно, не ограничевается сервисами из более чем одного процесса, и не решается переводом на Type=notify. Она вообще ортогональна существованию systemd. И идея её решения, очевидно, не взлетела, и уже наверное не взлетит. Если чтобы systemd не ругался - то проблема, очевидно, не в том, чтобы сделать хорошо, а в том, убрать конкретную ругань (которая не несёт практического смысла, см. ниже). И предолженный ранее workaround про sleep 0.1 - вполне себе в этом ключе же решение? > >> О каких именно "чуть менее, чем все существующие демоны" > >> сервисах Вы говорите? Есть еще кроме nginx примеры некорректного > >> поведения systemd-сервисов с Type=forking которые запускают много > >> дочерних процессов как это делает nginx или postfix? > > > Не вижу причин, почему демоны с "много дочерних процессов" должны > > отличаться от сервисов с "мало дочерних процессов". > > systemd однозначно определяет pid демонов состоящих из одного процесса > и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile= > - все будет работать как надо даже если они стартуют без синхронизации. > > Вот что говорит Lennart Poettering из Red Hat: > > If you use Type=forking, then you'll get away with not specifiying a > PID file in most cases, but it's racy as soon as you have more than > one daemon process, and nginx appears to be one of this kind, hence > please specify PIDFile=. > > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html Ну вот я посмотрел на это место чуть подробнее, и имею сказать, что это не совсем соответствует действительности. Единственное, для чего нужен PIDFile в случае nginx'а - это чтобы systemd нормально реагировал на binary upgrade. Для правильного детектирования основного процесса при запуске PIDFile не нужен, так как master-процесс - единственный, у кого parent'ом systemd, у остальных процессов parent'ом будет master. И соответственно все остальные процессы успешно отфильтрует вот этот код, https://github.com/systemd/systemd/blob/master/src/core/cgroup.c#L1727: /* Ignore processes that aren't our kids */ if (get_process_ppid(npid, &ppid) >= 0 && ppid != mypid) continue; Однако если PIDFile не указывать, то "service nginx upgrade" приведёт к тому, что после выхода старого мастера systemd будет считать, что nginx умер, и убьёт все новые процессы. Поэтому PIDFile указывать таки надо. Соответственно имеем то что имеем: PIDFile указывать надо, от этого на старте могут появляться сообщения про "PID file not ... yet?". Сообщения эти безвредные, и ни на что не влияют, кроме собственно появления самих сообщений. Если идти по пути синхронизации через pipe, то патч получается как-то такой. Не могу сказать, что он мне нравится, особенно в контексте решения задачи "чтобы у systemd в логе стало на одну строчку меньше". diff -r 325b3042edd6 src/core/nginx.c --- a/src/core/nginx.c Thu Nov 23 16:33:40 2017 +0300 +++ b/src/core/nginx.c Fri Nov 24 07:07:44 2017 +0300 @@ -361,6 +361,10 @@ return 1; } + if (ngx_daemon_sync(cycle->log) != NGX_OK) { + return 1; + } + if (ngx_log_redirect_stderr(cycle) != NGX_OK) { return 1; } diff -r 325b3042edd6 src/os/unix/ngx_daemon.c --- a/src/os/unix/ngx_daemon.c Thu Nov 23 16:33:40 2017 +0300 +++ b/src/os/unix/ngx_daemon.c Fri Nov 24 07:07:44 2017 +0300 @@ -9,10 +9,19 @@ #include +static ngx_fd_t ngx_daemon_fd = NGX_INVALID_FILE; + + ngx_int_t ngx_daemon(ngx_log_t *log) { - int fd; + u_char buf[1]; + ngx_fd_t fd, pp[2]; + + if (pipe(pp) == -1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "pipe() failed"); + return NGX_ERROR; + } switch (fork()) { case -1: @@ -20,9 +29,30 @@ return NGX_ERROR; case 0: + if (close(pp[0]) == -1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() pipe failed"); + return NGX_ERROR; + } + + ngx_daemon_fd = pp[1]; break; default: + if (close(pp[1]) == -1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() pipe failed"); + return NGX_ERROR; + } + + if (read(pp[0], buf, 1) != 1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "read() pipe failed"); + return NGX_ERROR; + } + + if (close(pp[0]) == -1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() failed"); + return NGX_ERROR; + } + exit(0); } @@ -68,3 +98,26 @@ return NGX_OK; } + + +ngx_int_t +ngx_daemon_sync(ngx_log_t *log) +{ + if (ngx_daemon_fd == NGX_INVALID_FILE) { + return NGX_OK; + } + + if (write(ngx_daemon_fd, "", 1) != 1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "write() failed"); + return NGX_ERROR; + } + + if (close(ngx_daemon_fd) == -1) { + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() failed"); + return NGX_ERROR; + } + + ngx_daemon_fd = NGX_INVALID_FILE; + + return NGX_OK; +} diff -r 325b3042edd6 src/os/unix/ngx_os.h --- a/src/os/unix/ngx_os.h Thu Nov 23 16:33:40 2017 +0300 +++ b/src/os/unix/ngx_os.h Fri Nov 24 07:07:44 2017 +0300 @@ -40,6 +40,7 @@ ngx_int_t ngx_os_specific_init(ngx_log_t *log); void ngx_os_specific_status(ngx_log_t *log); ngx_int_t ngx_daemon(ngx_log_t *log); +ngx_int_t ngx_daemon_sync(ngx_log_t *log); ngx_int_t ngx_os_signal_process(ngx_cycle_t *cycle, char *sig, ngx_pid_t pid); -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Fri Nov 24 08:06:52 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 24 Nov 2017 11:06:52 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171124041231.GN78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> Message-ID: <20171124080652.ozoyjy7xi6nvjrww@protva.ru> On Fri, Nov 24, 2017 at 07:12:31AM +0300, Maxim Dounin wrote: > + if (read(pp[0], buf, 1) != 1) { > + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "read() pipe failed"); > + return NGX_ERROR; > + } > + > + if (close(pp[0]) == -1) { > + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() failed"); "close() pipe failed" > + return NGX_ERROR; > + } > + > exit(0); > } > > @@ -68,3 +98,26 @@ > > return NGX_OK; > } > + > + > +ngx_int_t > +ngx_daemon_sync(ngx_log_t *log) > +{ > + if (ngx_daemon_fd == NGX_INVALID_FILE) { > + return NGX_OK; > + } > + > + if (write(ngx_daemon_fd, "", 1) != 1) { > + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "write() failed"); "write() pipe failed" > + return NGX_ERROR; > + } > + > + if (close(ngx_daemon_fd) == -1) { > + ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "close() failed"); "close() pipe failed" > + return NGX_ERROR; Можно ещё заменить "pp" на "sync_fd" / "sync_pipe". -- Eugene Berdnikov From nginx на mva.name Fri Nov 24 09:16:08 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 24 Nov 2017 12:16:08 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171124080652.ozoyjy7xi6nvjrww@protva.ru> References: <20171124041231.GN78325@mdounin.ru> <20171124080652.ozoyjy7xi6nvjrww@protva.ru> Message-ID: <8539635.2FDckjm5SZ@note> Прошу прощения за то, что вставляю свои пять копеек, но у меня, почему-то, на Gentoo NgX вполне замечательно стартует на SystemD без ругани, на которую жалуется ОП: ``` ноя 24 12:12:24 note systemd[1]: Starting The nginx HTTP and reverse proxy server... ноя 24 12:12:25 note nginx[17684]: nginx: the configuration file /etc/nginx/ nginx.conf syntax is ok ноя 24 12:12:25 note nginx[17684]: nginx: configuration file /etc/nginx/ nginx.conf test is successful ноя 24 12:12:25 note systemd[1]: Started The nginx HTTP and reverse proxy server. ``` Код nginx.service при этом такой: ``` [Unit] Description=The nginx HTTP and reverse proxy server After=network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill -QUIT $MAINPID [Install] WantedBy=multi-user.target ``` В связи с этим у меня возникает вопрос: а что я, собственно, делаю не так? From gmm на csdoc.com Fri Nov 24 11:30:41 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 24 Nov 2017 13:30:41 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171124041231.GN78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> Message-ID: <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> On 24.11.2017 6:12, Maxim Dounin wrote: >>> Но сама идея, что все должны сесть и заняться выпиливанием >>> стандартного паттерна, который работал десятки лет, и делать >>> вместо это что-то своё с синхронизацией - не взлетит. >> Эта идея уже взлетела. Если демон состоит из одного процесса >> - systemd может однозначно узнать его pid, проблемы могут возникать >> только с теми демонами, которые состоят из нескольких процессов. >> Из известных мне сервисов состоящих из более чем одного процесса: >> * postfix - сделали синхронизацию и проблем с systemd больше нет. >> * httpd - перевели на Type=notify и проблем с systemd больше нет. >> * php-fpm - перевели на Type=notify и проблем с systemd больше нет. >> * nginx - только с этим сервисом наблюдаются проблемы под systemd. > Давайте, всё-таки, опеределимся: мы за всё хорошее против всего > плохого (== чтобы демоны писали pid-файлы до выхода запущенного > процесса, потому что по другому - плохо), или вопрос исключительно > в том, чтобы systemd не ругался в логи? Так ведь systemd и ругается в логи потому что по другому - плохо. Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" будет глючить на системах, где nginx запускается в виде SysV сервиса. > Если за всё хорошее - то проблема, очевидно, не ограничевается > сервисами из более чем одного процесса, и не решается переводом на > Type=notify. Она вообще ортогональна существованию systemd. И > идея её решения, очевидно, не взлетела, и уже наверное не взлетит. В MacOS X есть launchd - там сервисам вообще запрещено делать fork() и вызывать функцию daemon() - и ничего, никто еще умер, все работает. https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html systemd - это такой же launchd, но для системы Linux. Только для своих конфигурационных файлов он использует ini синтаксис вместо формата xml и небезуспешно пытается быть обратно совместимым со старыми SysV Daemons Но свои специфичные требования к сервисам есть и у systemd: https://www.freedesktop.org/software/systemd/man/daemon.html 15. Call exit() in the original process. The process that invoked the daemon must be able to rely on that this exit() happens after initialization is complete and all external communication channels are established and accessible. Одним из таких communication channels как раз и является pid-файл. > Если чтобы systemd не ругался - то проблема, очевидно, не в том, > чтобы сделать хорошо, а в том, убрать конкретную ругань (которая > не несёт практического смысла, см. ниже). И предолженный ранее > workaround про sleep 0.1 - вполне себе в этом ключе же решение? sleep 0.1 - это race condition на ровном месте, плохой workaround. Лучше будет если такого workaround`а в unit-файлах nginx не делать. Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" глючит - это ведь отрицательно сказывается на репутации nginx. И эта проблема вообще ортогональна существованию systemd. >> systemd однозначно определяет pid демонов состоящих из одного процесса >> и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile= >> - все будет работать как надо даже если они стартуют без синхронизации. >> >> Вот что говорит Lennart Poettering из Red Hat: >> >> If you use Type=forking, then you'll get away with not specifiying a >> PID file in most cases, but it's racy as soon as you have more than >> one daemon process, and nginx appears to be one of this kind, hence >> please specify PIDFile=. >> >> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html > > Ну вот я посмотрел на это место чуть подробнее, и имею сказать, > что это не совсем соответствует действительности. Единственное, > для чего нужен PIDFile в случае nginx'а - это чтобы systemd > нормально реагировал на binary upgrade. > > Для правильного детектирования основного процесса при запуске > PIDFile не нужен, так как master-процесс - единственный, у кого > parent'ом systemd, у остальных процессов parent'ом будет master. > И соответственно все остальные процессы успешно отфильтрует вот > этот код, > https://github.com/systemd/systemd/blob/master/src/core/cgroup.c#L1727: > > /* Ignore processes that aren't our kids */ > if (get_process_ppid(npid, &ppid) >= 0 && ppid != mypid) > continue; > > Однако если PIDFile не указывать, то "service nginx upgrade" > приведёт к тому, что после выхода старого мастера systemd будет > считать, что nginx умер, и убьёт все новые процессы. Поэтому > PIDFile указывать таки надо. > > Соответственно имеем то что имеем: PIDFile указывать надо, от > этого на старте могут появляться сообщения про "PID file not ... yet?". > Сообщения эти безвредные, и ни на что не влияют, кроме собственно > появления самих сообщений. > > Если идти по пути синхронизации через pipe, то патч получается > как-то такой. Не могу сказать, что он мне нравится, особенно в > контексте решения задачи "чтобы у systemd в логе стало на одну > строчку меньше". Есть проблема "/etc/init.d/nginx start ; /etc/init.d/nginx stop" на старых системах, использующих SysV систему инициализации. И есть еще проблема не полной совместимости nginx с требованиями, которые systemd предъявляет к SysV Daemons - это имиджевая проблема. Сообщение "PID file not ... yet?" - это только следствие этих проблем. -- Best regards, Gena From nginx на mva.name Fri Nov 24 11:36:08 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 24 Nov 2017 14:36:08 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> References: <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> Message-ID: <8943928.sFZyPlO1mH@note> В письме от пятница, 24 ноября 2017 г. 14:30:41 MSK пользователь Gena Makhomed написал: > Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > глючит Опять же, данная команда на gentoo (на инстансах без systemd) у меня тоже не глючит. При любом количестве воркеров. И у меня всё тот же вопрос: что же я делаю не так и как мне воспроизвести вашу проблему? // просто мимокрокодил From annulen на yandex.ru Fri Nov 24 11:43:29 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Fri, 24 Nov 2017 14:43:29 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> Message-ID: <321721511523809@web22g.yandex.ru> 24.11.2017, 14:30, "Gena Makhomed" : > On 24.11.2017 6:12, Maxim Dounin wrote: > >>>>  Но сама идея, что все должны сесть и заняться выпиливанием >>>>  стандартного паттерна, который работал десятки лет, и делать >>>>  вместо это что-то своё с синхронизацией - не взлетит. > >>>  Эта идея уже взлетела. Если демон состоит из одного процесса >>>  - systemd может однозначно узнать его pid, проблемы могут возникать >>>  только с теми демонами, которые состоят из нескольких процессов. >>>  Из известных мне сервисов состоящих из более чем одного процесса: > >>>  * postfix - сделали синхронизацию и проблем с systemd больше нет. >>>  * httpd - перевели на Type=notify и проблем с systemd больше нет. >>>  * php-fpm - перевели на Type=notify и проблем с systemd больше нет. >>>  * nginx - только с этим сервисом наблюдаются проблемы под systemd. > >>  Давайте, всё-таки, опеределимся: мы за всё хорошее против всего >>  плохого (== чтобы демоны писали pid-файлы до выхода запущенного >>  процесса, потому что по другому - плохо), или вопрос исключительно >>  в том, чтобы systemd не ругался в логи? > > Так ведь systemd и ругается в логи потому что по другому - плохо. > Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > будет глючить на системах, где nginx запускается в виде SysV сервиса. > >>  Если за всё хорошее - то проблема, очевидно, не ограничевается >>  сервисами из более чем одного процесса, и не решается переводом на >>  Type=notify. Она вообще ортогональна существованию systemd. И >>  идея её решения, очевидно, не взлетела, и уже наверное не взлетит. > > В MacOS X есть launchd - там сервисам вообще запрещено делать fork() > и вызывать функцию daemon() - и ничего, никто еще умер, все работает. > https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html В daemontools, runit и т.п., которые появились еще раньше, fork тоже не поощряется > > systemd - это такой же launchd, но для системы Linux. Только для своих > конфигурационных файлов он использует ini синтаксис вместо формата xml > и небезуспешно пытается быть обратно совместимым со старыми SysV Daemons > > Но свои специфичные требования к сервисам есть и у systemd: > https://www.freedesktop.org/software/systemd/man/daemon.html > > 15. Call exit() in the original process. The process that invoked > the daemon must be able to rely on that this exit() happens > after initialization is complete and all external communication > channels are established and accessible. > > Одним из таких communication channels как раз и является pid-файл. > >>  Если чтобы systemd не ругался - то проблема, очевидно, не в том, >>  чтобы сделать хорошо, а в том, убрать конкретную ругань (которая >>  не несёт практического смысла, см. ниже). И предолженный ранее >>  workaround про sleep 0.1 - вполне себе в этом ключе же решение? > > sleep 0.1 - это race condition на ровном месте, плохой workaround. > Лучше будет если такого workaround`а в unit-файлах nginx не делать. > > Когда команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > глючит - это ведь отрицательно сказывается на репутации nginx. > И эта проблема вообще ортогональна существованию systemd. > >>>  systemd однозначно определяет pid демонов состоящих из одного процесса >>>  и поэтому для них в юнит-файле можно вообще не указывать опцию PIDFile= >>>  - все будет работать как надо даже если они стартуют без синхронизации. >>> >>>  Вот что говорит Lennart Poettering из Red Hat: >>> >>>  If you use Type=forking, then you'll get away with not specifiying a >>>  PID file in most cases, but it's racy as soon as you have more than >>>  one daemon process, and nginx appears to be one of this kind, hence >>>  please specify PIDFile=. >>> >>>  https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html >> >>  Ну вот я посмотрел на это место чуть подробнее, и имею сказать, >>  что это не совсем соответствует действительности. Единственное, >>  для чего нужен PIDFile в случае nginx'а - это чтобы systemd >>  нормально реагировал на binary upgrade. >> >>  Для правильного детектирования основного процесса при запуске >>  PIDFile не нужен, так как master-процесс - единственный, у кого >>  parent'ом systemd, у остальных процессов parent'ом будет master. >>  И соответственно все остальные процессы успешно отфильтрует вот >>  этот код, >>  https://github.com/systemd/systemd/blob/master/src/core/cgroup.c#L1727: >> >>                   /* Ignore processes that aren't our kids */ >>                   if (get_process_ppid(npid, &ppid) >= 0 && ppid != mypid) >>                           continue; >> >>  Однако если PIDFile не указывать, то "service nginx upgrade" >>  приведёт к тому, что после выхода старого мастера systemd будет >>  считать, что nginx умер, и убьёт все новые процессы. Поэтому >>  PIDFile указывать таки надо. >> >>  Соответственно имеем то что имеем: PIDFile указывать надо, от >>  этого на старте могут появляться сообщения про "PID file not ... yet?". >>  Сообщения эти безвредные, и ни на что не влияют, кроме собственно >>  появления самих сообщений. >> >>  Если идти по пути синхронизации через pipe, то патч получается >>  как-то такой. Не могу сказать, что он мне нравится, особенно в >>  контексте решения задачи "чтобы у systemd в логе стало на одну >>  строчку меньше". > > Есть проблема "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > на старых системах, использующих SysV систему инициализации. > > И есть еще проблема не полной совместимости nginx с требованиями, > которые systemd предъявляет к SysV Daemons - это имиджевая проблема. > > Сообщение "PID file not ... yet?" - это только следствие этих проблем. > > -- > Best regards, >   Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From pavel2000 на ngs.ru Fri Nov 24 11:58:08 2017 From: pavel2000 на ngs.ru (Pavel V.) Date: Fri, 24 Nov 2017 18:58:08 +0700 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> Message-ID: <1662204168.20171124185808@ngs.ru> Здравствуйте! > Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > будет глючить на системах, где nginx запускается в виде SysV сервиса. Никогда не возникало желания выполнить команду "/etc/init.d/nginx start ; /etc/init.d/nginx stop" Что я делаю не так, или чего не делаю? > - Доктор, когда я вот-вот-так делаю - у меня болит! :(( > - А вы вот-вот-так - не делайте. :-| -- С уважением, Pavel mailto:pavel2000 на ngs.ru From mdounin на mdounin.ru Fri Nov 24 12:59:08 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Nov 2017 15:59:08 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <8539635.2FDckjm5SZ@note> References: <20171124041231.GN78325@mdounin.ru> <20171124080652.ozoyjy7xi6nvjrww@protva.ru> <8539635.2FDckjm5SZ@note> Message-ID: <20171124125908.GP78325@mdounin.ru> Hello! On Fri, Nov 24, 2017 at 12:16:08PM +0300, Vadim A. Misbakh-Soloviov wrote: > Прошу прощения за то, что вставляю свои пять копеек, но у меня, почему-то, на > Gentoo NgX вполне замечательно стартует на SystemD без ругани, на которую > жалуется ОП: [...] > В связи с этим у меня возникает вопрос: а что я, собственно, делаю не так? Там race: - запущенный процесс делает fork() и выходит; - потомок делает setsid(), umask(), перенаправляет stdin/stdout в /dev/null, и уже после этого создаёт pid-файл. Соответственно systemd может успеть попытаться прочитать pid-файл до того, как он создан. Успеет или нет - зависит от количества процессоров и поведения шедулера. У меня получается воспроизвести проблему на виртуалке с Ubuntu после того, как я оставил в ней только один процессор. Где-то раз в 3-5 запусков он успевает. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Nov 24 13:33:39 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Nov 2017 16:33:39 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> Message-ID: <20171124133339.GR78325@mdounin.ru> Hello! On Fri, Nov 24, 2017 at 01:30:41PM +0200, Gena Makhomed wrote: > On 24.11.2017 6:12, Maxim Dounin wrote: > > >>> Но сама идея, что все должны сесть и заняться выпиливанием > >>> стандартного паттерна, который работал десятки лет, и делать > >>> вместо это что-то своё с синхронизацией - не взлетит. > > >> Эта идея уже взлетела. Если демон состоит из одного процесса > >> - systemd может однозначно узнать его pid, проблемы могут возникать > >> только с теми демонами, которые состоят из нескольких процессов. > >> Из известных мне сервисов состоящих из более чем одного процесса: > > >> * postfix - сделали синхронизацию и проблем с systemd больше нет. > >> * httpd - перевели на Type=notify и проблем с systemd больше нет. > >> * php-fpm - перевели на Type=notify и проблем с systemd больше нет. > >> * nginx - только с этим сервисом наблюдаются проблемы под systemd. > > > Давайте, всё-таки, опеределимся: мы за всё хорошее против всего > > плохого (== чтобы демоны писали pid-файлы до выхода запущенного > > процесса, потому что по другому - плохо), или вопрос исключительно > > в том, чтобы systemd не ругался в логи? > > Так ведь systemd и ругается в логи потому что по другому - плохо. > Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > будет глючить на системах, где nginx запускается в виде SysV сервиса. То есть боремся за всё хорошее против всего плохого, правильно я понял ответ? Ну вот тогда, как я уже неоднократно говорил - выбранная методика борьбы - не работает и не будет работать. И поведение nginx'а тут совершенно нерелевантно. Отдельно отмечу, что смысла в этой борьбе - приблизительно столько же, сколько смысла в команде "/etc/init.d/nginx start ; /etc/init.d/nginx stop". [...] -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri Nov 24 14:48:41 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 24 Nov 2017 16:48:41 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171124133339.GR78325@mdounin.ru> References: <20171122174314.GC78325@mdounin.ru> <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> <20171124133339.GR78325@mdounin.ru> Message-ID: <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> On 24.11.2017 15:33, Maxim Dounin wrote: >>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего >>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного >>> процесса, потому что по другому - плохо), или вопрос исключительно >>> в том, чтобы systemd не ругался в логи? >> Так ведь systemd и ругается в логи потому что по другому - плохо. >> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" >> будет глючить на системах, где nginx запускается в виде SysV сервиса. > То есть боремся за всё хорошее против всего плохого, правильно я > понял ответ? Есть спецификация на запуск сервисов под управлением systemd. Вопрос лишь в том, соответствует nginx этой спецификации или нет. nginx ведь соответствует например, спецификации на протокол HTTP, почему же он не может соответствовать спецификации из daemon(7)? Это создает проблемы при использовании legacy систем инициализации? Нет, наборот, решает имеющиеся проблемы с race conditions при старте. Не понимаю в чем тут проблема, если поддержка этой спецификации требует добавления в nginx всего нескольких десятков строк кода. > Ну вот тогда, как я уже неоднократно говорил - выбранная методика > борьбы - не работает и не будет работать. И поведение nginx'а тут > совершенно нерелевантно. Это не вопрос борьбы, это вопрос соответствия требованиям спецификации. Если в unit-файле nginx написано Type=forking - ожидается что nginx будет вести себя так, как того требует спецификация сервисов systemd. По поводу предложения "Проще всего, IMHO, это было бы заткнуть на уровне systemd, дожидаясь появления pid-файла при необходимости" В TODO файле systemd есть такая запись: "- introduce Type=pid-file" Это как раз и есть это предложение, просто оно еще не реализовано. > Отдельно отмечу, что смысла в этой борьбе - приблизительно столько > же, сколько смысла в команде "/etc/init.d/nginx start ; > /etc/init.d/nginx stop". Есть различные баги в софте, в частности - race conditions, Команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" - это просто пример, как можно этот баг воспроизвести. -- Best regards, Gena From nginx на mva.name Fri Nov 24 15:11:38 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 24 Nov 2017 18:11:38 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> References: <20171122174314.GC78325@mdounin.ru> <20171124133339.GR78325@mdounin.ru> <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> Message-ID: <11451035.csR0ij8iy5@note> В письме от пятница, 24 ноября 2017 г. 17:48:41 MSK пользователь Gena Makhomed написал: > nginx ведь соответствует например, спецификации на протокол HTTP, Например, потому что NginX — HTTP-сервер, > почему же он не может соответствовать спецификации из daemon(7)? а SystemD при этом — лишь **одна** из **множества** существующих init-систем на **одной** из **множества** операционных систем, на которых работает NginX. А ещё, потому что NginX соответствует спецификации daemon(3). Которая, в отличие от daemon(7), является релевантной для всех ОС (включая в т.ч. Linux) на которых существует соответствующая man-страница. В то время, как спецификация daemon(7) является релевантной только для systemd и существует только на системах с установленных systemd (потому что сама man- страница является частью systemd). Самим разработчикам NginX не интересно в работающий десятилетиями на множестве ОС воркфлоу вставлять пучок костылей для соответствия требованиям одного- единственного сервис-менеджера из множества. К тому же, особенно мило требование по их вставке выглядит в свете того, что за всё время существования SystemD его авторы до сих пор не хотят сделать возможность хендлить рестарт (а не просто stop+start), о которой говорилось в соседнем треде созданном вами. Т.е. картина такая: разработчики SystemD требуют чтобы под них подстраивались другие, при этом сами ни под чей воркфлоу подстроиться не хотят. Даже не смотря на его повсеместное (кроме systemd) существование десятилетиями. В связи с этим, как вам уже сказали: если **вам** это нужно — сделайте патч или наймите того, кто его сделает. И не просто патч, а соответствующий код-стайлу NginX и вставляющий как можно меньше костылей. И, крайне желательно, с вынесением всего этого в `--with-systemd`/`#ifdef WITH_SYSTEMD` (или типа того). Иначе весь этот тред — переливание из пустого в порожнее, т.к. разработчикам NginX нет ни интереса, ни стимула на ровном месте заниматься подобными непотребствами. И, к слову, как я говорил выше, на том же OpenRC (который, так-то, надстройка над SysV-init) подобных проблем с NginX не наблюдается. Интересно, почему бы это?.. From mdounin на mdounin.ru Fri Nov 24 19:43:24 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Nov 2017 22:43:24 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> References: <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> <20171124133339.GR78325@mdounin.ru> <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> Message-ID: <20171124194324.GS78325@mdounin.ru> Hello! On Fri, Nov 24, 2017 at 04:48:41PM +0200, Gena Makhomed wrote: > On 24.11.2017 15:33, Maxim Dounin wrote: > > >>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего > >>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного > >>> процесса, потому что по другому - плохо), или вопрос исключительно > >>> в том, чтобы systemd не ругался в логи? > > >> Так ведь systemd и ругается в логи потому что по другому - плохо. > >> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > >> будет глючить на системах, где nginx запускается в виде SysV сервиса. > > > То есть боремся за всё хорошее против всего плохого, правильно я > > понял ответ? > > Есть спецификация на запуск сервисов под управлением systemd. > Вопрос лишь в том, соответствует nginx этой спецификации или нет. Нет. Вопрос в том, соответствует ли эта "спецификация", придуманная авторами systemd, тому, как пишутся и работают демоны последние 25+ лет. И ответ - не соответствует. -- От, из-звольте. Уся рота, ч-черт бы ее побрал, идет не в ногу. Один п-подпоручик идет в ногу. [...] > В TODO файле systemd есть такая запись: "- introduce Type=pid-file" > Это как раз и есть это предложение, просто оно еще не реализовано. Вот и замечательно. Как доделают - проблема с сообщением решится сама собой. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Sat Nov 25 14:21:44 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 25 Nov 2017 16:21:44 +0200 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <20171124194324.GS78325@mdounin.ru> References: <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> <20171124133339.GR78325@mdounin.ru> <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> <20171124194324.GS78325@mdounin.ru> Message-ID: <50590b9e-3dbc-3abf-7328-1afcb469eae4@csdoc.com> On 24.11.2017 21:43, Maxim Dounin wrote: >>>>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего >>>>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного >>>>> процесса, потому что по другому - плохо), или вопрос исключительно >>>>> в том, чтобы systemd не ругался в логи? >>>> Так ведь systemd и ругается в логи потому что по другому - плохо. >>>> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" >>>> будет глючить на системах, где nginx запускается в виде SysV сервиса. >>> То есть боремся за всё хорошее против всего плохого, правильно я >>> понял ответ? >> Есть спецификация на запуск сервисов под управлением systemd. >> Вопрос лишь в том, соответствует nginx этой спецификации или нет. > Нет. Вопрос в том, соответствует ли эта "спецификация", > придуманная авторами systemd, тому, как пишутся и работают демоны > последние 25+ лет. И ответ - не соответствует. А как быть с тем, что гугл выдает примерно 51500 страниц, если в строке поиска задать: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. ? Ведь это всё отрицательным образом сказывается на имидже nginx. Можно ли пойти по второму пути и сделать в nginx workaround, чтобы systemd не ругался в логи? Например, в функции ngx_daemon() перед вызовом exit(0) добавить ngx_msleep(100) ? Этого вполне должно хватить. -- Best regards, Gena From slw на zxy.spb.ru Sat Nov 25 14:35:44 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sat, 25 Nov 2017 17:35:44 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <50590b9e-3dbc-3abf-7328-1afcb469eae4@csdoc.com> References: <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> <20171124133339.GR78325@mdounin.ru> <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> <20171124194324.GS78325@mdounin.ru> <50590b9e-3dbc-3abf-7328-1afcb469eae4@csdoc.com> Message-ID: <20171125143544.GG5355@zxy.spb.ru> On Sat, Nov 25, 2017 at 04:21:44PM +0200, Gena Makhomed wrote: > On 24.11.2017 21:43, Maxim Dounin wrote: > > >>>>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего > >>>>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного > >>>>> процесса, потому что по другому - плохо), или вопрос исключительно > >>>>> в том, чтобы systemd не ругался в логи? > > >>>> Так ведь systemd и ругается в логи потому что по другому - плохо. > >>>> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" > >>>> будет глючить на системах, где nginx запускается в виде SysV сервиса. > > >>> То есть боремся за всё хорошее против всего плохого, правильно я > >>> понял ответ? > > >> Есть спецификация на запуск сервисов под управлением systemd. > >> Вопрос лишь в том, соответствует nginx этой спецификации или нет. > > > Нет. Вопрос в том, соответствует ли эта "спецификация", > > придуманная авторами systemd, тому, как пишутся и работают демоны > > последние 25+ лет. И ответ - не соответствует. > > А как быть с тем, что гугл выдает примерно 51500 страниц, > если в строке поиска задать: > > systemd: PID file /var/run/nginx.pid not readable (yet?) after start. > > ? > > Ведь это всё отрицательным образом сказывается на имидже nginx. я уже не первый раз читаю про имидж nginx и отрицательный образ. и как-то не могу никак понять о чем речь-то? обычно для того, что бы имидж программы не портился его принято класть на нормальные, не помойные hdd/sdd, ну или если уж брать помойные носители, то собирать их в RAID (I -- Inexpensive). причем тут systemd? или поттеринг теперь занялся еще и тем, что стал портить имиджи програм? (это конечно странно, но с него станется). ну значит надо поставить флаг immutable на имидж. шоб неповадно было. From annulen на yandex.ru Sun Nov 26 01:47:12 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Sun, 26 Nov 2017 04:47:12 +0300 Subject: systemd: PID file /var/run/nginx.pid not readable (yet?) after start. In-Reply-To: <50590b9e-3dbc-3abf-7328-1afcb469eae4@csdoc.com> References: <20171123153754.GE78325@mdounin.ru> <6317ee69-71e3-8e64-36a9-c2057a351171@csdoc.com> <20171123171306.GH78325@mdounin.ru> <20171123210058.GM78325@mdounin.ru> <0463d337-3efb-66a8-2ee3-c057900e1b99@csdoc.com> <20171124041231.GN78325@mdounin.ru> <82bc920e-8484-bcd4-d9c3-672b258bec63@csdoc.com> <20171124133339.GR78325@mdounin.ru> <2b958d6b-1df3-b854-4bc1-deaa494acc69@csdoc.com> <20171124194324.GS78325@mdounin.ru> <50590b9e-3dbc-3abf-7328-1afcb469eae4@csdoc.com> Message-ID: <1207111511660832@web13o.yandex.ru> > On 24.11.2017 21:43, Maxim Dounin wrote: > >>>>>> Давайте, всё-таки, опеределимся: мы за всё хорошее против всего >>>>>> плохого (== чтобы демоны писали pid-файлы до выхода запущенного >>>>>> процесса, потому что по другому - плохо), или вопрос исключительно >>>>>> в том, чтобы systemd не ругался в логи? > >>>>> Так ведь systemd и ругается в логи потому что по другому - плохо. >>>>> Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop" >>>>> будет глючить на системах, где nginx запускается в виде SysV сервиса. > >>>> То есть боремся за всё хорошее против всего плохого, правильно я >>>> понял ответ? > >>> Есть спецификация на запуск сервисов под управлением systemd. >>> Вопрос лишь в том, соответствует nginx этой спецификации или нет. > >> Нет. Вопрос в том, соответствует ли эта "спецификация", >> придуманная авторами systemd, тому, как пишутся и работают демоны >> последние 25+ лет. И ответ - не соответствует. > > А как быть с тем, что гугл выдает примерно 51500 страниц, > если в строке поиска задать: > > systemd: PID file /var/run/nginx.pid not readable (yet?) after start. > > ? > > Ведь это всё отрицательным образом сказывается на имидже nginx. А на имидже systemd не сказывается, так как он уже давно ниже плинтуса :) > > Можно ли пойти по второму пути и сделать в nginx workaround, > чтобы systemd не ругался в логи? > > Например, в функции ngx_daemon() перед вызовом exit(0) > добавить ngx_msleep(100) ? Этого вполне должно хватить. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Mon Nov 27 03:10:03 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Sun, 26 Nov 2017 22:10:03 -0500 Subject: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm Message-ID: <1a0868ce0fe327ecf3d37c21c3265c32.NginxMailingListRussian@forum.nginx.org> [root на centos-7-4 ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) rpmbuild --rebuild nginx-1.13.7-1.el7_4.ngx.src.rpm sh: lsb_release: command not found error: /root/rpmbuild/SPECS/nginx.spec:28: bad %if condition Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277518,277518#msg-277518 From nginx-forum на forum.nginx.org Mon Nov 27 09:24:21 2017 From: nginx-forum на forum.nginx.org (Artemdno) Date: Mon, 27 Nov 2017 04:24:21 -0500 Subject: Listen ssl Message-ID: <1f576525a0efc10ada477eaca628a1fe.NginxMailingListRussian@forum.nginx.org> Здравствуйте, помогите христа ради. Есть три файла в sites-enabled, в каждом описано: server { listen 8080; server_name ; ssl on; ssl_certificate .crt; ssl_certificate_key .key; ssl_session_timeout 5m; ssl_protocols SSLv2 SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:/; } } Если в одном из файлов убрать ssl, То он всё равно ожидает https (появляется ошибка о попытке отправки http запроса, на https порт). Подскажите пожалуйста, почему появляется эта ошибка? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277519,277519#msg-277519 From vadim.lazovskiy на gmail.com Mon Nov 27 09:34:15 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Mon, 27 Nov 2017 12:34:15 +0300 Subject: Listen ssl In-Reply-To: <1f576525a0efc10ada477eaca628a1fe.NginxMailingListRussian@forum.nginx.org> References: <1f576525a0efc10ada477eaca628a1fe.NginxMailingListRussian@forum.nginx.org> Message-ID: Здравствуйте. Уберите из конфига ssl on; Используйте вместо него параметр ssl к директиве listen. 27 ноября 2017 г., 12:24 пользователь Artemdno написал: > Здравствуйте, помогите христа ради. > > Есть три файла в sites-enabled, в каждом описано: > > server { > listen 8080; > server_name ; > > ssl on; > > ssl_certificate .crt; > ssl_certificate_key .key; > > ssl_session_timeout 5m; > > ssl_protocols SSLv2 SSLv3 TLSv1; > ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+ > HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; > ssl_prefer_server_ciphers on; > > location / { > proxy_pass http://127.0.0.1:/; > } > } > > Если в одном из файлов убрать ssl, То он всё равно ожидает https > (появляется > ошибка о попытке отправки http запроса, на https порт). > Подскажите пожалуйста, почему появляется эта ошибка? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,277519,277519#msg-277519 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Tue Nov 28 02:56:57 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Mon, 27 Nov 2017 21:56:57 -0500 Subject: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm In-Reply-To: <1a0868ce0fe327ecf3d37c21c3265c32.NginxMailingListRussian@forum.nginx.org> References: <1a0868ce0fe327ecf3d37c21c3265c32.NginxMailingListRussian@forum.nginx.org> Message-ID: <412bc9a56c8dfef1c23ddc2689b79e38.NginxMailingListRussian@forum.nginx.org> Добрый день! Посмотрите эту ошибку? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277518,277530#msg-277530 From chipitsine на gmail.com Tue Nov 28 07:46:53 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 28 Nov 2017 12:46:53 +0500 Subject: =?UTF-8?B?0LrQsNC6INC/0YDQsNCy0LjQu9GM0L3QviDQv9GA0L7QutGB0LjRgNC+0LLQsNGC?= =?UTF-8?B?0Ywg0LLQtdCx0YHQvtC60LXRgtGLID8=?= Message-ID: Привет! в официальной документации https://nginx.ru/ru/docs/http/websocket.html есть пример map $http_upgrade $connection_upgrade { default upgrade; '' close; } получается, что соединение будет закрываться каждый раз. не будет ли логичнее сделать map $http_upgrade $connection_upgrade { default upgrade; '' ''; } ? или это какая-то задумка ? расскажите ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Nov 28 13:42:59 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 28 Nov 2017 16:42:59 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINCy0LXQsdGB0L7QutC10YLRiyA/?= In-Reply-To: References: Message-ID: <20171128134259.GF78325@mdounin.ru> Hello! On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote: > Привет! > > в официальной документации https://nginx.ru/ru/docs/http/websocket.html > > есть пример > > map $http_upgrade $connection_upgrade { > default upgrade; > '' close; > } > > > получается, что соединение будет закрываться каждый раз. > > не будет ли логичнее сделать > > map $http_upgrade $connection_upgrade { > default upgrade; > '' ''; > } > > ? > > или это какая-то задумка ? расскажите ? По умолчанию соединения к бэкенду используют HTTP/1.0 и закрываются каждый раз. Если хочется, чтобы они не закрывались, нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не отправлял на бэкенд "Connection: close", а также включить кэш keepalive-соединений в блоке upstream. Подробнее об этом рассказано тут: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive Если хочется использовать keepalive к бэкендам одновременно с проксированием вебсокетов - то пример в статье про проксирование вебсокетов, естественно, не будет работать как есть, в нём надо "close" заменить на пустую строку - как и предложено выше. Однако если это сделать без включения кэша keepalive-соединений, то никаких положительных последствий не будет. Наоборот, появится лишняя задержка перед закрытием соединения, и закрывать соединения будет nginx, а не бэкенд, что в свою очередь может привести к проблемам, так как time-wait сокеты вместо стороны бэкенда окажутся на стороне nginx'а. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Nov 28 14:04:05 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 28 Nov 2017 19:04:05 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINCy0LXQsdGB0L7QutC10YLRiyA/?= In-Reply-To: <20171128134259.GF78325@mdounin.ru> References: <20171128134259.GF78325@mdounin.ru> Message-ID: 28 ноября 2017 г., 18:42 пользователь Maxim Dounin написал: > Hello! > > On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote: > > > Привет! > > > > в официальной документации https://nginx.ru/ru/docs/http/websocket.html > > > > есть пример > > > > map $http_upgrade $connection_upgrade { > > default upgrade; > > '' close; > > } > > > > > > получается, что соединение будет закрываться каждый раз. > > > > не будет ли логичнее сделать > > > > map $http_upgrade $connection_upgrade { > > default upgrade; > > '' ''; > > } > > > > ? > > > > или это какая-то задумка ? расскажите ? > > По умолчанию соединения к бэкенду используют HTTP/1.0 и > закрываются каждый раз. Если хочется, чтобы они не закрывались, > нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не > отправлял на бэкенд "Connection: close", а также включить кэш > keepalive-соединений в блоке upstream. Подробнее об этом > рассказано тут: > собственно, в примере про вебсокеты у вас: proxy_http_version 1.1; > > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive > > Если хочется использовать keepalive к бэкендам одновременно с > проксированием вебсокетов - то пример в статье про проксирование > вебсокетов, естественно, не будет работать как есть, в нём надо > "close" заменить на пустую строку - как и предложено выше. > > Однако если это сделать без включения кэша keepalive-соединений, > то никаких положительных последствий не будет. Наоборот, появится > лишняя задержка перед закрытием соединения, и закрывать соединения > будет nginx, а не бэкенд, что в свою очередь может привести к > проблемам, так как time-wait сокеты вместо стороны бэкенда > окажутся на стороне nginx'а. > это понятно. как минимум, стоит это обговорить, в текущем виде пример неочевидный. подозреваю, что его копипастят и драг-н-дропят по принципу "ну это же официальная документация, там фигню не посоветуют" > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Nov 28 14:08:53 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 28 Nov 2017 19:08:53 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINCy0LXQsdGB0L7QutC10YLRiyA/?= In-Reply-To: <20171128134259.GF78325@mdounin.ru> References: <20171128134259.GF78325@mdounin.ru> Message-ID: (сорян за топпостинг) давно была мысль. настройки кипэлайвов, насколько, я понимаю, будут работать в любой комбинации, даже в таких 1) в апстриме НЕ указан keepalive, в правилах проксирования указан 2) в апстриме указан keepalive, в правилах проксирования протокол 1.0 как писал Максим, это будет приводить к невидимому на первый взгляд неоптимальному использованию ресурсов сервера. можно как-то на уровне проверки синтаксиса ставить emerg для таких разбалансировок ? 28 ноября 2017 г., 18:42 пользователь Maxim Dounin написал: > Hello! > > On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote: > > > Привет! > > > > в официальной документации https://nginx.ru/ru/docs/http/websocket.html > > > > есть пример > > > > map $http_upgrade $connection_upgrade { > > default upgrade; > > '' close; > > } > > > > > > получается, что соединение будет закрываться каждый раз. > > > > не будет ли логичнее сделать > > > > map $http_upgrade $connection_upgrade { > > default upgrade; > > '' ''; > > } > > > > ? > > > > или это какая-то задумка ? расскажите ? > > По умолчанию соединения к бэкенду используют HTTP/1.0 и > закрываются каждый раз. Если хочется, чтобы они не закрывались, > нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не > отправлял на бэкенд "Connection: close", а также включить кэш > keepalive-соединений в блоке upstream. Подробнее об этом > рассказано тут: > > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive > > Если хочется использовать keepalive к бэкендам одновременно с > проксированием вебсокетов - то пример в статье про проксирование > вебсокетов, естественно, не будет работать как есть, в нём надо > "close" заменить на пустую строку - как и предложено выше. > > Однако если это сделать без включения кэша keepalive-соединений, > то никаких положительных последствий не будет. Наоборот, появится > лишняя задержка перед закрытием соединения, и закрывать соединения > будет nginx, а не бэкенд, что в свою очередь может привести к > проблемам, так как time-wait сокеты вместо стороны бэкенда > окажутся на стороне nginx'а. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From annulen на yandex.ru Tue Nov 28 14:10:04 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 28 Nov 2017 17:10:04 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINCy0LXQsdGB0L7QutC10YLRiyA/?= In-Reply-To: References: <20171128134259.GF78325@mdounin.ru> Message-ID: <41761511878204@web54g.yandex.ru> 28.11.2017, 17:04, "Илья Шипицин" : > 28 ноября 2017 г., 18:42 пользователь Maxim Dounin написал: >> Hello! >> >> On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote: >> >>> Привет! >>> >>> в официальной документации https://nginx.ru/ru/docs/http/websocket.html >>> >>> есть пример >>> >>>     map $http_upgrade $connection_upgrade { >>>         default upgrade; >>>         ''      close; >>>     } >>> >>> >>> получается, что соединение будет закрываться каждый раз. >>> >>> не будет ли логичнее сделать >>> >>>     map $http_upgrade $connection_upgrade { >>>         default upgrade; >>>         ''      ''; >>>     } >>> >>> ? >>> >>> или это какая-то задумка ? расскажите ? >> >> По умолчанию соединения к бэкенду используют HTTP/1.0 и >> закрываются каждый раз.  Если хочется, чтобы они не закрывались, >> нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не >> отправлял на бэкенд "Connection: close", а также включить кэш >> keepalive-соединений в блоке upstream.  Подробнее об этом >> рассказано тут: > > собственно, в примере про вебсокеты у вас: > > proxy_http_version 1.1; > >> http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive >> >> Если хочется использовать keepalive к бэкендам одновременно с >> проксированием вебсокетов - то пример в статье про проксирование >> вебсокетов, естественно, не будет работать как есть, в нём надо >> "close" заменить на пустую строку - как и предложено выше. >> >> Однако если это сделать без включения кэша keepalive-соединений, >> то никаких положительных последствий не будет.  Наоборот, появится >> лишняя задержка перед закрытием соединения, и закрывать соединения >> будет nginx, а не бэкенд, что в свою очередь может привести к >> проблемам, так как time-wait сокеты вместо стороны бэкенда >> окажутся на стороне nginx'а. > > это понятно. как минимум, стоит это обговорить, в текущем виде пример неочевидный. > подозреваю, что его копипастят и драг-н-дропят по принципу "ну это же официальная документация, там фигню не посоветуют" Я думаю, имелось в виду, что location с websocket не должен обрабатывать посторонние HTTP-запросы, и для них соединения можно смело разрывать и не тратить место в кэше. > >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> 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 --  Regards, Konstantin From mdounin на mdounin.ru Tue Nov 28 14:25:14 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 28 Nov 2017 17:25:14 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDRgtGMINCy0LXQsdGB0L7QutC10YLRiyA/?= In-Reply-To: References: <20171128134259.GF78325@mdounin.ru> Message-ID: <20171128142514.GG78325@mdounin.ru> Hello! On Tue, Nov 28, 2017 at 07:04:05PM +0500, Илья Шипицин wrote: > 28 ноября 2017 г., 18:42 пользователь Maxim Dounin > написал: > > > Hello! > > > > On Tue, Nov 28, 2017 at 12:46:53PM +0500, Илья Шипицин wrote: > > > > > Привет! > > > > > > в официальной документации https://nginx.ru/ru/docs/http/websocket.html > > > > > > есть пример > > > > > > map $http_upgrade $connection_upgrade { > > > default upgrade; > > > '' close; > > > } > > > > > > > > > получается, что соединение будет закрываться каждый раз. > > > > > > не будет ли логичнее сделать > > > > > > map $http_upgrade $connection_upgrade { > > > default upgrade; > > > '' ''; > > > } > > > > > > ? > > > > > > или это какая-то задумка ? расскажите ? > > > > По умолчанию соединения к бэкенду используют HTTP/1.0 и > > закрываются каждый раз. Если хочется, чтобы они не закрывались, > > нужно явно сказать nginx'у, чтобы использовал HTTP/1.1 и не > > отправлял на бэкенд "Connection: close", а также включить кэш > > keepalive-соединений в блоке upstream. Подробнее об этом > > рассказано тут: > > собственно, в примере про вебсокеты у вас: > > proxy_http_version 1.1; И этого, очевидно, недостаточно. > > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive > > > > Если хочется использовать keepalive к бэкендам одновременно с > > проксированием вебсокетов - то пример в статье про проксирование > > вебсокетов, естественно, не будет работать как есть, в нём надо > > "close" заменить на пустую строку - как и предложено выше. > > > > Однако если это сделать без включения кэша keepalive-соединений, > > то никаких положительных последствий не будет. Наоборот, появится > > лишняя задержка перед закрытием соединения, и закрывать соединения > > будет nginx, а не бэкенд, что в свою очередь может привести к > > проблемам, так как time-wait сокеты вместо стороны бэкенда > > окажутся на стороне nginx'а. > > > > это понятно. как минимум, стоит это обговорить, в текущем виде пример > неочевидный. > подозреваю, что его копипастят и драг-н-дропят по принципу "ну это же > официальная документация, там фигню не посоветуют" В текущем виде пример совместим с поведением по умолчанию. А обговаривать все варианты совмещения всех примеров из документации - это, извините, комбинаторный взрыв получится, мы такого, боюсь, не потянем. -- Maxim Dounin http://mdounin.ru/ From nginx на kinetiksoft.com Tue Nov 28 15:52:30 2017 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Tue, 28 Nov 2017 18:52:30 +0300 Subject: =?UTF-8?B?bmdpbngg0Lgg0YHQvNC10L3QsCDRgdC40LzQu9C40L3QutC+0LI=?= Message-ID: <1851826.gxnkTGDYC3@cybernote> Здравствуйте! nginx 1.12.2, debian 8, php-fpm (5.6) *# *nginx -V Есть самописное приложение на php. У него есть две версии: stable и current. Для быстрой смены используется следующая схема: /var/www/stable/ - тут лежит stable /var/www/current/ - тут лежит current /var/www/html - симлинк на на /var/www/stable или /var/www/current В nginx пыха сконфигурирована как root /var/www/html; location / { fastcgi_pass unix:/run/php-fpm.socket; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/index.php; } Проблема в том. что при переключение stable->current (и наоборот), которая происходит примерно так: # /var/www/html указывает на /var/www/stable , переключаемся на current rm /var/www/html; ln -s /var/www/current/ /var/www/html до упора используются файлы из старой директории (stable в примере выше). Не помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно reload, не уверен) nginx. Хотелось бы 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк? 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в принципе готовы поменять воркфлоу, но пока не понимаем как. С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Tue Nov 28 16:52:29 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Tue, 28 Nov 2017 18:52:29 +0200 Subject: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm In-Reply-To: <412bc9a56c8dfef1c23ddc2689b79e38.NginxMailingListRussian@forum.nginx.org> References: <1a0868ce0fe327ecf3d37c21c3265c32.NginxMailingListRussian@forum.nginx.org> <412bc9a56c8dfef1c23ddc2689b79e38.NginxMailingListRussian@forum.nginx.org> Message-ID: Вам что-то мешает установить redhat-lsb-core? 2017-11-28 4:56 GMT+02:00 Dothris : > Добрый день! > Посмотрите эту ошибку? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,277518,277530#msg-277530 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Nov 28 16:56:50 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Tue, 28 Nov 2017 11:56:50 -0500 Subject: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm In-Reply-To: References: Message-ID: Мне интересно почему его нет в buildrequires или requires Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277518,277550#msg-277550 From defan на nginx.com Tue Nov 28 17:03:50 2017 From: defan на nginx.com (Andrei Belov) Date: Tue, 28 Nov 2017 20:03:50 +0300 Subject: error: nginx.spec:28: bad %if condition nginx-1.13.7-1.el7_4.ngx.src.rpm In-Reply-To: References: Message-ID: > On 28 Nov 2017, at 19:56, Dothris wrote: > > Мне интересно почему его нет в buildrequires или requires Есть: http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l20 Но все макросы обрабатываются видимо до проверок собственно по директивам spec-файла, отсюда ошибка. Сходу не придумывается решение, но при случае поразмышляем, что тут можно сделать. From sytar.alex на gmail.com Tue Nov 28 18:24:02 2017 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 28 Nov 2017 21:24:02 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0LzQtdC90LAg0YHQuNC80LvQuNC90LrQvtCy?= In-Reply-To: <1851826.gxnkTGDYC3@cybernote> References: <1851826.gxnkTGDYC3@cybernote> Message-ID: 28 ноября 2017 г., 18:52 пользователь Иван написал: > Здравствуйте! > > > > nginx 1.12.2, debian 8, php-fpm (5.6) > > > /var/www/html - симлинк на на /var/www/stable или /var/www/current > > > ... > Хотелось бы > > 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк? > > 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в > принципе готовы поменять воркфлоу, но пока не понимаем как. > > Nginx тут не причем. Смотрите в сторону настроек вашего php-бекенда, в частности кеша realpath. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Nov 28 18:34:02 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 28 Nov 2017 23:34:02 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0LzQtdC90LAg0YHQuNC80LvQuNC90LrQvtCy?= In-Reply-To: <1851826.gxnkTGDYC3@cybernote> References: <1851826.gxnkTGDYC3@cybernote> Message-ID: 28 ноября 2017 г., 20:52 пользователь Иван написал: > Здравствуйте! > > > > nginx 1.12.2, debian 8, php-fpm (5.6) > > # nginx -V > nginx version: nginx/1.12.2 > built by gcc 4.9.2 (Debian 4.9.2-10) > built with OpenSSL 1.0.1t 3 May 2016 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/va > r/log/nginx/error.log --http-log-path=/var/log/nginx/access.log > --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/c > ache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cach > e/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp > --user=nginx --group=nginx --with-compat --with-file-aio --with-threads > --with-http_addition_ > module --with-http_auth_request_module --with-http_dav_module > --with-http_flv_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_mp4_mod > ule --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_sta > tus_module --with-http_sub_module --with-http_v2_module --with-mail > --with-mail_ssl_module --with-stream --with-stream_realip_module > --with-stream_ssl_module --w > ith-stream_ssl_preread_module --with-cc-opt='-g -O2 > -fstack-protector-strong -Wformat -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,- > z,relro -Wl,-z,now -Wl,--as-needed -pie' > > > > Есть самописное приложение на php. У него есть две версии: stable и > current. Для быстрой смены используется следующая схема: > > /var/www/stable/ - тут лежит stable > > /var/www/current/ - тут лежит current > > /var/www/html - симлинк на на /var/www/stable или /var/www/current > > > > В nginx пыха сконфигурирована как > > > > root /var/www/html; > > location / { > > fastcgi_pass unix:/run/php-fpm.socket; > сделайте тут проксирование на апстрим (в котором перечислены несколько бекендов) fastcgi_connect_timeout сделайте минимальным > include fastcgi_params; > > fastcgi_param SCRIPT_FILENAME $document_root/index.php; > > } > > > > Проблема в том. что при переключение stable->current (и наоборот), > достаточно будет запустить тот или иной бекенд (не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp проксировать) > которая происходит примерно так: > > # /var/www/html указывает на /var/www/stable , переключаемся на current > > rm /var/www/html; ln -s /var/www/current/ /var/www/html > > > > до упора используются файлы из старой директории (stable в примере выше). > Не помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно > reload, не уверен) nginx. > > Хотелось бы > > 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк? > > 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в > принципе готовы поменять воркфлоу, но пока не понимаем как. > > > > С уважением, Иван. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sargaskn на gmail.com Tue Nov 28 19:46:48 2017 From: sargaskn на gmail.com (Sargas) Date: Tue, 28 Nov 2017 21:46:48 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0LzQtdC90LAg0YHQuNC80LvQuNC90LrQvtCy?= In-Reply-To: References: <1851826.gxnkTGDYC3@cybernote> Message-ID: Приветствую. 1) Закомментируйте в файле fastcgi_params параметр SCRIPT_FILENAME , если еще не сделали этого 2) fastcgi_param SCRIPT_FILENAME $document_root/index.php; замените $document_root на $realpath_root fastcgi_param SCRIPT_FILENAME $realpath_root/index.php; Почитать про переменную можно тут http://nginx.org/ru/docs/http/ngx_http_core_module.html И как выше советовали почитайте про php realpath cache чтобы было понимание. 3) > # /var/www/html указывает на /var/www/stable , переключаемся на current >rm /var/www/html; ln -s /var/www/current/ /var/www/html Я бы переделал чуть по другому. ln -s path_to_latest_release /var/www/html_tmp mv -Tf /var/www/html_tmp /var/www/html 28 ноября 2017 г., 20:34 пользователь Илья Шипицин написал: > > > 28 ноября 2017 г., 20:52 пользователь Иван > написал: > >> Здравствуйте! >> >> >> >> nginx 1.12.2, debian 8, php-fpm (5.6) >> >> # nginx -V >> nginx version: nginx/1.12.2 >> built by gcc 4.9.2 (Debian 4.9.2-10) >> built with OpenSSL 1.0.1t 3 May 2016 >> TLS SNI support enabled >> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx >> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf >> --error-log-path=/va >> r/log/nginx/error.log --http-log-path=/var/log/nginx/access.log >> --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock >> --http-client-body-temp-path=/var/c >> ache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp >> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp >> --http-uwsgi-temp-path=/var/cach >> e/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp >> --user=nginx --group=nginx --with-compat --with-file-aio --with-threads >> --with-http_addition_ >> module --with-http_auth_request_module --with-http_dav_module >> --with-http_flv_module --with-http_gunzip_module >> --with-http_gzip_static_module --with-http_mp4_mod >> ule --with-http_random_index_module --with-http_realip_module >> --with-http_secure_link_module --with-http_slice_module >> --with-http_ssl_module --with-http_stub_sta >> tus_module --with-http_sub_module --with-http_v2_module --with-mail >> --with-mail_ssl_module --with-stream --with-stream_realip_module >> --with-stream_ssl_module --w >> ith-stream_ssl_preread_module --with-cc-opt='-g -O2 >> -fstack-protector-strong -Wformat -Werror=format-security >> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,- >> z,relro -Wl,-z,now -Wl,--as-needed -pie' >> >> >> >> Есть самописное приложение на php. У него есть две версии: stable и >> current. Для быстрой смены используется следующая схема: >> >> /var/www/stable/ - тут лежит stable >> >> /var/www/current/ - тут лежит current >> >> /var/www/html - симлинк на на /var/www/stable или /var/www/current >> >> >> >> В nginx пыха сконфигурирована как >> >> >> >> root /var/www/html; >> >> location / { >> >> fastcgi_pass unix:/run/php-fpm.socket; >> > > сделайте тут проксирование на апстрим (в котором перечислены несколько > бекендов) > fastcgi_connect_timeout сделайте минимальным > > > >> include fastcgi_params; >> >> fastcgi_param SCRIPT_FILENAME $document_root/index.php; >> >> } >> >> >> >> Проблема в том. что при переключение stable->current (и наоборот), >> > > достаточно будет запустить тот или иной бекенд > > (не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp > проксировать) > > > >> которая происходит примерно так: >> >> # /var/www/html указывает на /var/www/stable , переключаемся на current >> >> rm /var/www/html; ln -s /var/www/current/ /var/www/html >> >> >> >> до упора используются файлы из старой директории (stable в примере выше). >> Не помогает ни очистка opcache, ни рестарт пыхи. Только restart (возможно >> reload, не уверен) nginx. >> >> Хотелось бы >> >> 1) понять почему так. nginx где-то как-то кеширует куда указывает симлинк? >> >> 2) избежать этого ("троганья" nginx (в идеале и рестарта php-fpm), в >> принципе готовы поменять воркфлоу, но пока не понимаем как. >> >> >> >> С уважением, Иван. >> >> _______________________________________________ >> 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 > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Tue Nov 28 20:59:46 2017 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Tue, 28 Nov 2017 23:59:46 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0LzQtdC90LAg0YHQuNC80LvQuNC90LrQvtCy?= In-Reply-To: References: <1851826.gxnkTGDYC3@cybernote> Message-ID: <2138257.sk7FxDi3IJ@cybernote> Здравствуйте! В письме от вторник, 28 ноября 2017 г. 21:34:02 MSK пользователь Илья Шипицин написал: > > сделайте тут проксирование на апстрим (в котором перечислены несколько > бекендов) > fastcgi_connect_timeout сделайте минимальным > > > достаточно будет запустить тот или иной бекенд > > (не уверен, что с unix-сокетами получится, в крайнем случае можно на tcp > проксировать) > Мне в итоге помог предложенный чуть ранее и дополненный тут: https:// stackoverflow.com/questions/23737627/php-opcache-reset-symlink-style-deployment/ 23904770#23904770 совет сделать fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $realpath_root; Меня теперь волнует не выполняет ли nginx тот самый "тяжелый" (как описано, например, https://habrahabr.ru/post/266909/) realpath при использовании $realpath_root. По непосредственно вашему способу вопрос только один, учитывая исторически багнутый reload в php-fpm не понятно как запускать\останавливать один пул php, не трогая другие. С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Wed Nov 29 14:10:46 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 29 Nov 2017 16:10:46 +0200 Subject: =?UTF-8?B?0JTQvtC60YPQvNC10L3RgtCw0YbQuNGPLCDQtNC40YDQtdC60YLQuNCy0LAgcGlk?= Message-ID: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> Здравствуйте, All! В документации по директиве pid есть ошибки: http://nginx.org/ru/docs/ngx_core_module.html#pid http://nginx.org/en/docs/ngx_core_module.html#pid Default: pid nginx.pid; На самом деле значение по-умолчанию для директивы pid берется из аргумента configure --pid-path= А если аргумент configure --pid-path не задан, тогда значение по-умолчанию равно logs/nginx.pid Например, для официальных linux-сборок с сайта nginx.org будет такое значение Default: pid /var/run/nginx.pid; А для официальных windows-сборок с сайта nginx.org будет такое значение Default: pid logs/nginx.pid; -- Best regards, Gena From mdounin на mdounin.ru Wed Nov 29 15:50:44 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 29 Nov 2017 18:50:44 +0300 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjywg0LTQuNGA0LXQutGC0LjQstCw?= =?UTF-8?B?IHBpZA==?= In-Reply-To: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> References: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> Message-ID: <20171129155044.GJ78325@mdounin.ru> Hello! On Wed, Nov 29, 2017 at 04:10:46PM +0200, Gena Makhomed wrote: > Здравствуйте, All! > > В документации по директиве pid есть ошибки: > > http://nginx.org/ru/docs/ngx_core_module.html#pid > http://nginx.org/en/docs/ngx_core_module.html#pid > > Default: pid nginx.pid; > > На самом деле значение по-умолчанию для директивы pid > берется из аргумента configure --pid-path= > > А если аргумент configure --pid-path не задан, > тогда значение по-умолчанию равно logs/nginx.pid > > Например, для официальных linux-сборок с сайта nginx.org > будет такое значение Default: pid /var/run/nginx.pid; > > А для официальных windows-сборок с сайта nginx.org > будет такое значение Default: pid logs/nginx.pid; По очевидным причинам документация не может отражать значение, специфичное для конкретной сборки. Так что мы там указываем значение по умолчанию, которое таки по умолчанию. Какими именно параметрами configure можно переопределить какие значения - сейчас документировано в выводе "configure --help": --error-log-path=PATH set error log pathname --pid-path=PATH set nginx.pid pathname --lock-path=PATH set nginx.lock pathname --user=USER set non-privileged user for worker processes --group=GROUP set non-privileged group for worker processes --http-log-path=PATH set http access log pathname --http-client-body-temp-path=PATH set path to store http client request body temporary files --http-proxy-temp-path=PATH set path to store http proxy temporary files --http-fastcgi-temp-path=PATH set path to store http fastcgi temporary files --http-uwsgi-temp-path=PATH set path to store http uwsgi temporary files --http-scgi-temp-path=PATH set path to store http scgi temporary files Частично эта же информация есть на странице http://nginx.org/en/docs/configure.html. Возможно, стоит добавить эту информацию в описания соответствующих директив (в виде note?). Patches, что называется, are welcome. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Wed Nov 29 18:05:04 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 29 Nov 2017 20:05:04 +0200 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjywg0LTQuNGA0LXQutGC0LjQstCw?= =?UTF-8?B?IHBpZA==?= In-Reply-To: <20171129155044.GJ78325@mdounin.ru> References: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> <20171129155044.GJ78325@mdounin.ru> Message-ID: On 29.11.2017 17:50, Maxim Dounin wrote: > Patches, что называется, are welcome. # HG changeset patch # User Gena Makhomed # Date 1511977733 -7200 # Wed Nov 29 19:48:53 2017 +0200 # Node ID 41edc73c0662fa9d62cb2cc7983fd9068fd9b390 # Parent 26e547b1022d5e64fe5dd4060f64f15c678c2e8a Updated documentation of directive "pid". diff -r 26e547b1022d -r 41edc73c0662 xml/ru/docs/ngx_core_module.xml --- a/xml/ru/docs/ngx_core_module.xml Mon Nov 27 11:56:06 2017 +0300 +++ b/xml/ru/docs/ngx_core_module.xml Wed Nov 29 19:48:53 2017 +0200 @@ -401,12 +401,19 @@ -файл -nginx.pid +имя файла +Зависит от параметров сборки nginx main -Задаёт файл, в котором будет храниться номер (PID) главного процесса. +Задаёт имя файла, в котором будет храниться идентификатор (PID) главного процесса nginx. +Значение по умолчанию задается в момент конфигурирования nginx параметром configure --pid-path. +Узнать значение по умолчанию для директивы pid можно запустив команду nginx -V +и посмотрев на значение параметра configure --pid-path. + + + +Не рекомендуется явно указывать значение директивы pid в конфигурационном файле. From mdounin на mdounin.ru Wed Nov 29 18:47:36 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 29 Nov 2017 21:47:36 +0300 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjywg0LTQuNGA0LXQutGC0LjQstCw?= =?UTF-8?B?IHBpZA==?= In-Reply-To: References: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> <20171129155044.GJ78325@mdounin.ru> Message-ID: <20171129184736.GK78325@mdounin.ru> Hello! On Wed, Nov 29, 2017 at 08:05:04PM +0200, Gena Makhomed wrote: > On 29.11.2017 17:50, Maxim Dounin wrote: > > > Patches, что называется, are welcome. > > # HG changeset patch > # User Gena Makhomed > # Date 1511977733 -7200 > # Wed Nov 29 19:48:53 2017 +0200 > # Node ID 41edc73c0662fa9d62cb2cc7983fd9068fd9b390 > # Parent 26e547b1022d5e64fe5dd4060f64f15c678c2e8a > Updated documentation of directive "pid". > > diff -r 26e547b1022d -r 41edc73c0662 xml/ru/docs/ngx_core_module.xml > --- a/xml/ru/docs/ngx_core_module.xml Mon Nov 27 11:56:06 2017 +0300 > +++ b/xml/ru/docs/ngx_core_module.xml Wed Nov 29 19:48:53 2017 +0200 > @@ -401,12 +401,19 @@ > > > > -файл > -nginx.pid > +имя файла Использование пробела тут ломает синтаксис - получается, что директива принимает два праметра, "имя" и "файла". Не надо так. > +Зависит от параметров сборки nginx > main Это необычайно информативно, и наверное всё, что можно тут сделать, это осознать, что некоторые идеи - просто плохие. > > > -Задаёт файл, в котором будет храниться номер (PID) > главного процесса. > +Задаёт имя файла, в котором будет храниться > идентификатор (PID) главного процесса nginx. > +Значение по умолчанию задается в момент конфигурирования nginx > параметром configure --pid-path. > +Узнать значение по умолчанию для директивы pid можно > запустив команду nginx -V > +и посмотрев на значение параметра configure --pid-path. > + Это мало соответствует тому, что хотелось бы видеть в описании директивы. > + > + > +Не рекомендуется явно указывать значение директивы > pid в конфигурационном файле. > Это не соответствует действительности. PID-файл можно и нужно задавать во многих ситуациях, например - если на машине запускается несколько независимых экземпляров nginx'а. Скажем, в портах FreeBSD такое поддерживается из коробки штатными rc-скриптами. > > Отмечу также в скобках, что - не стоит смешивать несколько изменений в один патч; - при смысловых изменениях содержимого документации следует менять ревизию в заголовке соответствующего файл. Это позволяет показывать на сайте плашку "этот перевод может быть устаревшим, смотрите английскую версию для ознакомления с последними изменениями", если перевод по какой-то причине не обновлён до текущей версии. - русский язык - не единственный язык документации, и делать патчи только на один язык - плохая идея. Более того, основной язык документации - английский, см. выше про ревизии, так что обычно лучше начинать с него. - в предыдущем письме было перечислено 11 параметров configure, которые влияют на значения различных директив. Нет никакого смысла дублировать эту информацию в описании одной из директив, и не дублировать в описаниях остальных. Наоборот, есть смысл так не делать: текущий подход может быть не очень удобен для новичков, ни разу не сталкивавшихся с configure, но консистентен и логичен. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Nov 30 09:10:09 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 30 Nov 2017 11:10:09 +0200 Subject: =?UTF-8?B?0L3QtdGB0LrQvtC70YzQutC+INC90LXQt9Cw0LLQuNGB0LjQvNGL0YUg0Y3QutC3?= =?UTF-8?B?0LXQvNC/0LvRj9GA0L7QsiBuZ2lueCfQsA==?= In-Reply-To: <20171129184736.GK78325@mdounin.ru> References: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> <20171129155044.GJ78325@mdounin.ru> <20171129184736.GK78325@mdounin.ru> Message-ID: <68a53dde-5104-9462-fb30-fcb2f3e860af@csdoc.com> On 29.11.2017 20:47, Maxim Dounin wrote: > например - если на машине > запускается несколько независимых экземпляров nginx'а. Скажем, в > портах FreeBSD такое поддерживается из коробки штатными > rc-скриптами. Кстати, в Linux это тоже поддерживается из коробки. Но наверное такая возможность в Linux мало кому нужна, раз она до сих пор не появилась в официальных сборках nginx для Linux? /etc/systemd/system/nginx на .service [Unit] Description=nginx %I Documentation=http://nginx.org/en/docs/ After=network-online.target remote-fs.target nss-lookup.target Wants=network-online.target [Service] Type=forking PIDFile=/var/run/nginx-%i.pid ExecStart=/usr/sbin/nginx -c /etc/nginx/%i.conf -g 'pid /var/run/nginx-%i.pid;' ExecReload=/bin/kill -s HUP $MAINPID [Install] WantedBy=multi-user.target ==================================================================== /etc/nginx/static.conf events { worker_connections 1024; } http { server { listen 8001; return 200 "static\n"; } } ==================================================================== /etc/nginx/dynamic.conf events { worker_connections 1024; } http { server { listen 8002; return 200 "dynamic\n"; } } ==================================================================== # systemctl daemon-reload # systemctl start nginx # systemctl start nginx на static # systemctl start nginx на dynamic # curl localhost:8001 static # curl localhost:8002 dynamic # ls -1 /var/run/nginx* /var/run/nginx-dynamic.pid /var/run/nginx-static.pid /var/run/nginx.pid -- Best regards, Gena From gmm на csdoc.com Thu Nov 30 11:40:57 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 30 Nov 2017 13:40:57 +0200 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjywg0LTQuNGA0LXQutGC0LjQstCw?= =?UTF-8?B?IHBpZA==?= In-Reply-To: <20171129184736.GK78325@mdounin.ru> References: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> <20171129155044.GJ78325@mdounin.ru> <20171129184736.GK78325@mdounin.ru> Message-ID: <0e1a807f-044e-f481-c1bf-00177bcd53e4@csdoc.com> On 29.11.2017 20:47, Maxim Dounin wrote: >> -nginx.pid >> +Зависит от параметров сборки nginx >> main > Это необычайно информативно, и наверное всё, что можно тут > сделать, это осознать, что некоторые идеи - просто плохие. С моей точки зрения, информация в документации должна быть прежде всего достоверной. "Значение по умолчанию" - это то значение которое примет директива, если она будет отсутствовать в конфиге или будет закомментирована. Если в документации явно указано какое-то одно значение по умолчанию, а на самом деле у директивы будет совсем другое значение по умолчанию, то это, с моей точки зрения, - достаточно грубая ошибка в документации, которую следует исправить тем или иным способом. Идеальным вариантом, с моей точки зрения, было бы сделать так: Defined at compile time. В виде html это выглядело бы так: Default: Defined at compile time. где текст "Defined at compile time" будет гиперссылкой. И в документе default_values.html для всех 11 директив описать способ как можно узнать их значение по умолчанию с помощью команды nginx -V Но xmllint ругается, что Element default was declared #PCDATA but contains non text nodes >> +Значение по умолчанию задается в момент конфигурирования nginx >> параметром configure --pid-path. >> +Узнать значение по умолчанию для директивы pid можно >> запустив команду nginx -V >> +и посмотрев на значение параметра configure --pid-path. > Это мало соответствует тому, что хотелось бы видеть в описании > директивы. Предложите лучший вариант как исправить эти ошибки в документации. >> + >> +Не рекомендуется явно указывать значение директивы >> pid в конфигурационном файле. >> > > Это не соответствует действительности. PID-файл можно и нужно > задавать во многих ситуациях, например - если на машине > запускается несколько независимых экземпляров nginx'а. Скажем, в > портах FreeBSD такое поддерживается из коробки штатными > rc-скриптами. В портах FreeBSD используется аргумент командной строки nginx -g \"pid ${pidfile};\": https://github.com/freebsd/freebsd-ports/blob/master/www/nginx/files/nginx.in#L64 Если директиву pid указать и в командной строке и в конфиге, тогда nginx будет ругаться при старте на такой конфиг: nginx: [emerg] "pid" directive is duplicate in /etc/nginx/nginx.conf:2 Можно ли подробнее узнать про "многие ситуации", когда необходимо задавать значение директивы pid в конфиге nginx? С моей точки зрения, будет больше вреда чем пользы от явного определения пользователями значения директивы pid в конфигурационном файле nginx. Часть ошибок systemd: PID file /var/run/nginx.pid not readable (yet?) after start. происходит именно из-за того что в unit-файле одно значение PIDFile= а в конфигурационном файле указано другое значение для директивы pid. Другая часть ошибок systemd: PID file /var/run/nginx.pid not readable (yet?) after start. происходит из-за того, что nginx зачем-то не совместим с systemd. Это Вы знаете, что сообщения эти "безвредные", да и то, только в том случае если в PIDFile= и в директиве pid указано одинаковое значение. Но пользователи nginx этого ведь не знают! И они продолжают безуспешно искать решение как убрать эти сообщения об ошибках из лог-файлов. Хотя проблема то легко решается на стороне nginx патчем в одну строчку. http://mailman.nginx.org/pipermail/nginx-devel/2017-November/010658.html -- Best regards, Gena From nginx на kinetiksoft.com Thu Nov 30 14:05:34 2017 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Thu, 30 Nov 2017 17:05:34 +0300 Subject: =?UTF-8?B?0K7QvdC40LrRgS3RgdC+0LrQtdGCINC4IGZhc3RjZ2ku?= Message-ID: <1854285.iv6Aee6HSk@cybernote> Здравствуйте! Имеет ли смысл включать keepalive для подключения к php-fpm через юникс-сокет? Попробовал сейчас включить, используя: upstream e_php { server unix:/run/php-fpm-e.socket; keepalive 200; } location ~* \.php$ { fastcgi_pass e_php; fastcgi_keep_conn on; } Смотрю в статус пула php-fpm, там скорость изменения показателя "accepted conn" за секунду (в среднем 500 cps) не изменяется по сравнению с конфигурацией location ~* \.php$ { fastcgi_pass unix:/run/php-fpm-e.socket; } Я что-то неправильно делаю\понимаю? С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Nov 30 15:39:55 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 30 Nov 2017 18:39:55 +0300 Subject: =?UTF-8?B?UmU6INCu0L3QuNC60YEt0YHQvtC60LXRgiDQuCBmYXN0Y2dpLg==?= In-Reply-To: <1854285.iv6Aee6HSk@cybernote> References: <1854285.iv6Aee6HSk@cybernote> Message-ID: <3058100.OGUa2WidhI@vbart-workstation> On Thursday 30 November 2017 17:05:34 Иван wrote: > Здравствуйте! > > Имеет ли смысл включать keepalive для подключения к php-fpm через юникс-сокет? > [..] Особого смысла нет. -- Валентин Бартенев From mdounin на mdounin.ru Thu Nov 30 17:02:35 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 30 Nov 2017 20:02:35 +0300 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjywg0LTQuNGA0LXQutGC0LjQstCw?= =?UTF-8?B?IHBpZA==?= In-Reply-To: <0e1a807f-044e-f481-c1bf-00177bcd53e4@csdoc.com> References: <196af91a-15b3-c3c3-788b-86b05613d4e2@csdoc.com> <20171129155044.GJ78325@mdounin.ru> <20171129184736.GK78325@mdounin.ru> <0e1a807f-044e-f481-c1bf-00177bcd53e4@csdoc.com> Message-ID: <20171130170235.GN78325@mdounin.ru> Hello! On Thu, Nov 30, 2017 at 01:40:57PM +0200, Gena Makhomed wrote: > On 29.11.2017 20:47, Maxim Dounin wrote: > > >> -nginx.pid > >> +Зависит от параметров сборки nginx > >> main > > > Это необычайно информативно, и наверное всё, что можно тут > > сделать, это осознать, что некоторые идеи - просто плохие. > > С моей точки зрения, > информация в документации должна быть прежде всего достоверной. > > "Значение по умолчанию" - это то значение которое примет директива, > если она будет отсутствовать в конфиге или будет закомментирована. Значение по умолчанию - это ещё и то значение, которое примет директива, если будет отсутствовать соответствующий параметр сборки. В этом месте, кстати, косяк, который совсем просто исправить - вместо "nginx.pid" должно быть "logs/nginx.pid". Патч: # HG changeset patch # User Maxim Dounin # Date 1512060425 -10800 # Thu Nov 30 19:47:05 2017 +0300 # Node ID 8f885a69374ddf67ff9400c7892f020b88f41839 # Parent 05f5bfdaffa3b71299ae378a37c2902c0e6825f1 Fixed the "pid" directive default value. diff --git a/xml/en/docs/ngx_core_module.xml b/xml/en/docs/ngx_core_module.xml --- a/xml/en/docs/ngx_core_module.xml +++ b/xml/en/docs/ngx_core_module.xml @@ -10,7 +10,7 @@ + rev="25">
@@ -404,7 +404,7 @@ the JIT support is enabled via the file -nginx.pid +logs/nginx.pid main diff --git a/xml/ru/docs/ngx_core_module.xml b/xml/ru/docs/ngx_core_module.xml --- a/xml/ru/docs/ngx_core_module.xml +++ b/xml/ru/docs/ngx_core_module.xml @@ -10,7 +10,7 @@ + rev="25">
@@ -402,7 +402,7 @@ load_module modules/ngx_mail_module.so; файл -nginx.pid +logs/nginx.pid main [...] > >> +Значение по умолчанию задается в момент конфигурирования nginx > >> параметром configure --pid-path. > >> +Узнать значение по умолчанию для директивы pid можно > >> запустив команду nginx -V > >> +и посмотрев на значение параметра configure --pid-path. > > > Это мало соответствует тому, что хотелось бы видеть в описании > > директивы. > > Предложите лучший вариант как исправить эти ошибки в документации. Я предложил ещё в первом письме этого треда - сделать note. И в нём написать, что значение по умолчанию может быть переопределено с помощью соответствующего параметра configure. Собственно, я тогда же попросил Ярослава, который у нас занимается документацией, на это посмотреть, и заодно привести в порядок configure.html. (Отмечу в скобках, что, скажем, в документации Apache для ServerRoot приблизительно так и сделано, https://httpd.apache.org/docs/2.4/mod/core.html#serverroot. А вот в описании PidFile не указано, что его значение по умолчанию переопределяется с помощью "-D DEFAULT_PIDLOG=...". Хватит это терпеть!) > >> + > >> +Не рекомендуется явно указывать значение директивы > >> pid в конфигурационном файле. > >> > > > > Это не соответствует действительности. PID-файл можно и нужно > > задавать во многих ситуациях, например - если на машине > > запускается несколько независимых экземпляров nginx'а. Скажем, в > > портах FreeBSD такое поддерживается из коробки штатными > > rc-скриптами. > > В портах FreeBSD используется аргумент командной строки > nginx -g \"pid ${pidfile};\": > > https://github.com/freebsd/freebsd-ports/blob/master/www/nginx/files/nginx.in#L64 > > Если директиву pid указать и в командной строке и в конфиге, > тогда nginx будет ругаться при старте на такой конфиг: > > nginx: [emerg] "pid" directive is duplicate in /etc/nginx/nginx.conf:2 > > Можно ли подробнее узнать про "многие ситуации", > когда необходимо задавать значение директивы pid в конфиге nginx? > > С моей точки зрения, будет больше вреда чем пользы от явного определения > пользователями значения директивы pid в конфигурационном файле nginx. Если хочется вдаваться в семантические различия "-g" и собственно конфигурационного файла, то pid именно в конфигурационном файле обычно проще и удобнее указывать, если хочется запускать несколько экземпляров nginx'а без использования скриптов, которые умеют делать это через "-g". Или когда хочется запустить nginx, стоящий в системе, под непривелигированным пользователем - для тестов, например. [...] > Другая часть ошибок > systemd: PID file /var/run/nginx.pid not readable (yet?) after start. > происходит из-за того, что nginx зачем-то не совместим с systemd. > > Это Вы знаете, что сообщения эти "безвредные", да и то, только в том > случае если в PIDFile= и в директиве pid указано одинаковое значение. > > Но пользователи nginx этого ведь не знают! И они продолжают безуспешно > искать решение как убрать эти сообщения об ошибках из лог-файлов. > > Хотя проблема то легко решается на стороне nginx патчем в одну строчку. > http://mailman.nginx.org/pipermail/nginx-devel/2017-November/010658.html По этому вопросу я уже сказал всё, что считаю нужным, и не планирую к нему возвращатья. Спасибо. -- Maxim Dounin http://mdounin.ru/