Re: cache file has too long header
Может лучше будет создать тикет здесь, чтобы не затерялось? https://trac.nginx.org/nginx/report/1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,286008#msg-286008 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Non-idempotent requests vs. upstream failover
Спасибо, а логируется ли в таких случаях в error log? Или только если все апстримы фейлнули? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285751,285753#msg-285753 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Non-idempotent requests vs. upstream failover
В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих апстримах? По идее должен т.к. запрос никем не был принят и обработан. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285751,285751#msg-285751 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: cache file has too long header
Ни одной записи за сутки! Вот вам фидбяк ) Спасибо. Надеюсь патч появится в релизах. Для его проявления не нужно каких-то крупных деплоев, если я правильно понял, а только чтобы апстрим возвращал нгинксу Vary для кешируемого ресурса. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285705#msg-285705 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: cache file has too long header
cache loader давно вышел, новых записей "too long header" в логе пока нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285692#msg-285692 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: cache file has too long header
Что любопытно после релоада нет ни одной ошибки, хотя раньше хотя бы раз в минуту было. Наверное пока cache loader запущен этих ситуаций не возникает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285691#msg-285691 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: cache file has too long header
Пропатчил, построил, перезапустил через роллинг апгрейд (USR+QUIT). Я так понимаю изменение для новых файлов будет актуально т.к. хедер поменялся. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285690#msg-285690 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: cache file has too long header
А это не повлияет на другие ресурсы, кроме maps? Например если будет закеширован контент, отличающийся по языку, он правильно будет отдан? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285686#msg-285686 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: cache file has too long header
Спасибо, а чего оно за полтора года не перекочевало из devel в mainline? У нас кеш 3 уровней, поддерживать патч на каждом из них как-то не то. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285681#msg-285681 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
cache file has too long header
Эта ошибка часто в логе для разных файлов. В гугле нашел что это решается увеличением proxy_buffer_size, но он и так у нас 8k. Подскажите как решить. Версия 1.16.1, OS FreeBSD 11.3. Из-за этой ошибки кеш игнорируется и ресурс запрашивается из апстрима, а это дорогой контент (google maps). Проблема только с этими ресурсами, другие кешируются нормально. Урл не такой уж и длинный, вроде. Пример ошибки: 2019/09/23 21:04:01 [crit] 95594#100948: *426913488 cache file "/usr/home/nginx/cache/myproj/maps/d/2d/28889e499a0f9ef187ba9fb63270c2dd" has too long header, client: 172.16.1.16, server: assets.example.com, request: "GET /maps/api/staticmap?key=AIzaSyBsXrvwBUBTrAMP0K-uCSJaH2cKU4xLPu4=12.412358%2C53.823786=320x100=11 HTTP/1.1", host: "assets.example.com", referrer: "https://example.com/foo/bar;. proxy_temp_path /usr/home/nginx/temp; proxy_http_version 1.1; proxy_headers_hash_max_size 1024; proxy_headers_hash_bucket_size 128; proxy_buffer_size 8k; proxy_connect_timeout 15s; proxy_send_timeout 5s; proxy_cache_path /usr/home/nginx/cache/myproj/maps levels=1:2 keys_zone=myproj-maps:128m inactive=30d max_size=8g; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285677#msg-285677 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Актуальна ли proxy cache path inactive=NNN между рестартами?
У нас на некоторых серверах inactive стоит 90 дней, что будет если nginx перезагрузить до этого времени, сохранится ли время последнего запроса к кешированному ресурсу? Я попытался сам разобраться по коду но там сложно. file->accessed = now; в ./src/core/ngx_open_file_cache.c И потом в ngx_http_file_cache_update() не увидел что поле acessed пишется. Может в другом месте где-то? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285333,285333#msg-285333 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: signer certificate not found после обновления
А можно вообще вернуться на родную openssl из фришки 11.х? Как она, стабильна? Вопросы лицензии и разного уровня "свободы" между "open" и "libre" мне безразличны. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285300#msg-285300 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: signer certificate not found после обновления
В портах фришки есть еще libressl-devel, там версия 3.0.0, пересобрал nginx с ней - то же самое. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285299#msg-285299 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: signer certificate not found после обновления
Я избавился от ворнингов временно просто перестроив с openssl :( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285298#msg-285298 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: signer certificate not found после обновления
Не знаете есть ли обновления? Сейчас в nginx вышла дырка в http2 и пришлось обновляться с 1.16.0 до 1.16.1, но ворнинги от ssl_stapling вернулись. Дело в том что сайтов много, релоад в рамках общей задачи мы делаем довольно часто и это видит каждый пользователь, это засоряет экран и неизбежно приведет к увеличению вопросов в саппорт, т.е. ко мне ) Не хотелось бы переходить на openssl пока это есть. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285297#msg-285297 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
Спасибо за ответ. Буферизация конечно включена, мне просто показалось что желаемое поведение (одновременный прием от апстрима и отправка клиенту) происходит только при выключенной буферизации. Размер буфера в несколько десятков кб роли не играет, это почти одновременно. У нас в основном картинки по несколько сот кб. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285155#msg-285155 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
Просто эта цитата в доках на английском говорит, что такое бывает при выключенном буферинге. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285153#msg-285153 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
Меня вот это немного смутило: "When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. " http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering Получается когда buffering включен, то наоборот, контент читается полностью перед началом отдачи клиенту. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285150#msg-285150 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Проксирование, буфер, лаги
Допустим если включено кеширование через proxy_cache, а также включено proxy_buffering (по умолчанию). Что происходит когда клиент запрашивает ресурс которого нет в кеше? Он сначала полностью скачивается из апстрима, кешируется, и только потом начинает отдаваться клиенту? И если таких уровней апстримов 2 или более, то лаг получения контента клиентом увеличивается грубо говоря в 2 или более раз? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285149#msg-285149 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
could not allocate node in cache keys zone "xxx"
Когда cache loader читает эакешированные файлы при запуске nginx, если proxy_cache_path max_size недостаточно велика, вот такие ошибки начинают сыпаться под конец. Насколько это плохо? Может это повлиять на невозможность кэшировать новые файлы, и в целом на нормальную работу? Можно чтобы это предотвратить выделить сразу много памяти, все равно как я понял nginx выделяет эту память мелкими порциями и используется в RSS не больше, чем нужно, так ли это? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285024,285024#msg-285024 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL сертификаты
> Если загрузка кэша не завершена - nginx при обращении к элементу > кэша, которого ещё нет в памяти, явно проверяет, есть ли > соответствующий файл на диске. То есть к лишним обращениям на > бэкенд это не приводит. Глядя на объемы памяти RSS, а также на текущий обрабатываемый каталог из вывода lsof, у меня такое впечатление что при SIGHUP nginx и запуске второго cache loader (первый при этом не умирает, убиваю его через TERM вручную) уже прочитанные объекты из shared memory не стираются, т.е. он просто продолжает откуда его прервали. Так ли это? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284958#msg-284958 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL сертификаты
Спасибо огромное за инфу! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284955#msg-284955 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL сертификаты
И еще параллельно такой вопрос возник: у нас крутящиеся диски на одном из серверов, и proxy_cache_path levels=1:2 все это приводит к тому, что в каждой директории где-то 3-4 тысячи файлов (я так понимаю поменять на 2:2 + reload уже нельзя?). cache_loader при старте работает довольно долго, но не грузит. Он очень мало CPU времени тратит или дискового, за сутки работы сейчас он потратил 0:04.37 (согласно ps) это 4 минуты, но он не заканчивается. lsof показывает что он очень много времени проводит на каждой из директорий кэша. А их тысячи. Надеюсь он не читает весь файл (преимущественно картинки), а только его начало с заголовками? )) Может ли его такая тормознутость привести к повторному запросу ресурса из источника и повторному кэшированию? Что делает nginx когда в кэше пока объекта нет, пытается ли сам к диску обратиться? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284953#msg-284953 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL сертификаты
Спасибо! Да, проверил, если не меняется ничего, то cache loader при релоаде не запускается. Я просто релоадил когда что-то менял, поэтому подумал что всегда так ) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284952#msg-284952 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SSL сертификаты
Можно как-то обойтись без reload (SIGHUP) nginx для того чтобы он перечитал с диска сертификаты (ssl_certificate)? Без этого он не бывает в курсе что они были обновлены. Но у релоад есть плохая штука что он наверняка забывает такие вещи как inactive=nnn в директиве proxy_cache_path, и если reload происходит раз в неделю, то любой inactive выше недели по сути ничего не делает. Также каждый релоад требует перечтения всех имеющихся данных cache loader'ом, а когда таких данных сотни гигов и диски (пока :)) крутящиеся, директива max_size не способна ограничивать дисковое пространство (т.к. пока loader все файлы не перечитает nginx не знает сколько пространства занято, если не ошибаюсь). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284950,284950#msg-284950 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
proxy_next_upstream & HTTP 502
У нас стоит: proxy_next_upstream error timeout http_500 http_502 http_503 http_504; Иногда в случае если один из апстримов в дауне в access.log появляются подобные строчки: 10.10.10.10 - S387DE34EI-1557637722 [12/May/2019:05:08:42 +] "GET /blah/blah HTTP/1.1" 502 12001 "-" "- example.com" "-" nginx логирует запрос только если попробовал все апстримы, или после каждого? Здесь больше похоже на второе. Можно ли как-то настроить чтобы логировался только результат последнего попробованного апстрима? Он и будет результатом запроса. nginx version: nginx/1.14.0 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284130,284130#msg-284130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"
Вот эта сборка с LibreSSL проблемная. Без нее (если убрать DEFAULT_VERSIONS+=ssl=libressl из /etc/make.conf или просто поставить пакет) нет ворнингов. [rihad@master /usr/local/etc/nginx]$ nginx -V nginx version: nginx/1.16.0 built with LibreSSL 2.9.1 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-debug --modules-path=/usr/local/libexec/nginx --with-file-aio --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_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-stream_ssl_preread_module --with-threads --add-dynamic-module=/usr/ports/www/nginx/work/ngx_brotli-8104036 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284082,284089#msg-284089 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"
Нашел причину. Дело в том, что нам нужен модуль brotli, а его в дефолтном пакете nginx на FreeBSD нет, поэтому строим сами www/nginx из порта, и она строится с LibreSSL. Вот с ней эти SSL stapling ворнинги бывают. Не уверен кому адресовать ) [rihad@master /usr/local/etc/nginx]$ nginx -V nginx version: nginx/1.16.0 built with LibreSSL 2.9.1 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-debug --modules-path=/usr/local/libexec/nginx --with-file-aio --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_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-stream_ssl_preread_module --with-threads --add-dynamic-module=/usr/ports/www/nginx/work/ngx_brotli-8104036 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284082,284088#msg-284088 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"
-BEGIN CERTIFICATE- MIIFsjCCBJqgAwIBAgISA1J3jfFIPKXDLBQ8ihTsBqlrMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA0MDkxODIyNDFaFw0x OTA3MDgxODIyNDFaMCcxJTAjBgNVBAMTHHR1cmJvYXotMTM5NTEwNjc0LmF6c3Rh Z2UuaW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNww06PtB5nP25 rQ2hYlhqx4POuTxCaDcHRg36t2oGeMTkFC75qBl+DjyXxJmlMsObEO5nt5zgaqcL Jl49s0acI/yA+hSh7vQpZRZ+4/jQ11R8QLd/9oOrhUqJ9fxgzHitsFIRFeh0pNxW eROmDqYJlSMEr5wxmmJtWEEMbLlFxIm/2/NUovXrZJOsoc5bx1sdsJnFpumdeFbU aYG1vPxD9NN5sGgwLFHdK3QDp8RdLGqV5ylhN6kadgnQElRpIaX9QNyRANUnNeGX jj3wuiovL9xx0gR+wcatMFc4y3JJORkcLtEk28y6qEcNQ0g5jYbqh1317Y7ByH0d BVJLm7djAgMBAAGjggKzMIICrzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYI KwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFHE9h0j5 aniSTd8SMYcz0E08fFe4MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyh MG8GCCsGAQUFBwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgz LmxldHNlbmNyeXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgz LmxldHNlbmNyeXB0Lm9yZy8wagYDVR0RBGMwYYIfcnUudHVyYm9hei0xMzk1MTA2 NzQuYXpzdGFnZS5pboIgc3NsLnR1cmJvYXotMTM5NTEwNjc0LmF6c3RhZ2UuaW6C HHR1cmJvYXotMTM5NTEwNjc0LmF6c3RhZ2UuaW4wTAYDVR0gBEUwQzAIBgZngQwB AgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRz ZW5jcnlwdC5vcmcwggEDBgorBgEEAdZ5AgQCBIH0BIHxAO8AdgDiaUuuJujpQAno hhu2O4PUPuf+dIj7pI8okwGd3fHb/gAAAWoDjW7TAAAEAwBHMEUCIQDpdUACdcIx U0al7y8pAA6mfkDmXqKVSU8gOGc3YihxywIgE8+nQjzXKYSLCoDLA+fB27SjVwrS mtVec9UN/cf+IvgAdQApPFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTlRUf0eAAA AWoDjWzkAAAEAwBGMEQCIDxpqP3iNu0/PpXG9UDV6cKYLrhKNIs8TTvaTUMV0o4S AiBy+XNTIij/IjcwEOcG/GVWlTVQMq2vH9N9nmSCUwviuDANBgkqhkiG9w0BAQsF AAOCAQEACto3pd6I2VMWl5mgbw+/A9SDgFW2saw1Ju3iIcYP37uWeCzFwZZXg1pP Lf4mgfxiE2Qyv3J9KFZNklBGJ2Ga/PaP861uib0Y1l8dOcADFPNvjuThpm3537Zy I7hr63bE6qnDrwitleZJcb4SOW46cme81DmW9uZBtMSUrAlL2dbU5/PH+YjSeNwq JYndjTX4NAUmLyTF/H4IpsOLsWcIprGMUX+CvmoonN/Ona8gUSvQS3UzCdfgzgHZ KW3m6iYwz3GeAJ1gK0XKZKMK31jDV3S1rNWcXuClgRHKQq75JpCfL3Iu50soiH5p es5SViQLNlbEjdAOSS55Jic36Nog3Q== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8 SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0 Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj /PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/ wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6 KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg== -END CERTIFICATE- Последняя версия acme.sh сует пустую строку между первым и вторым, это никак не влияет ни на что. $ nginx -V nginx version: nginx/1.14.2 built with OpenSSL 1.0.2o-freebsd 27 Mar 2018 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 --modules-path=/usr/local/libexec/nginx --with-file-aio --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_v2_module --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-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --without-mail_imap_module
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"
Эти варны возникли при чтении конфига после обновления до nginx с 1.14.2 до 1.16.0 (ОС: FreeBSD 11.2). Даунгрейд до 1.14.2 убирает сообщения.. Используем сертфикаты Let's Encrypt и клиент acme.sh Конфиг SSL Stapling: ssl_stapling on; ssl_stapling_verify on; Типичный конфиг домена (коих много): ssl_certificate /home/acme/.acme.sh/example.com/fullchain.cer; ssl_certificate_key /home/acme/.acme.sh/example.com/example.com.key; Внутри fullchain.cer сидят два сертификата, второй из которых всегда одинаков для всех. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284082,284082#msg-284082 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Отлично, проверил - проблема решилась. Всем спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280336#msg-280336 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Jochen Neumeister наконец ответил: i work on it :-) joneum Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280313#msg-280313 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx mainline vs nginx stable
> Наверное есть смысл перейти на использование ветки mainline 1.15.х > Она не менее стабильная, чем stable, и на основании ветки mainline > создается коммерческая версия "NGINX Plus". Спасибо за детальный обзор, но пора энтузиазма давно прошла )) Сейчас важно чтобы штука стабильно работала, чтобы секьюрные дырки лечились вовремя, чтобы нововведений несовместимых не было и так далее - т.е. чтобы будни админа упрощались, а не усложнялись )) В этом плане stable вполне устраивает. Но вот такой косяк вышел с относительно новой технологией Brotli, и то потому, что начальство решило на передовой волне идти когда это было совсем не обязательно )) Кстати баг затрагивал mainline (www/nginx-devel) тоже, просто там по стечению обстоятельств раньше пофиксилось - разные майнтейнеры. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280307#msg-280307 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Спасибо, отписал майнтейнеру порта www/nginx joneum@ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280225#msg-280225 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Dmytro Lavryk Wrote: --- > Точно. Там люди ходят. Не самые посещаемые сайты, но все же... > > curl -H 'Accept-Encoding: br' -I https://site.address/ > ... > content-encoding: br Вы используете brotli on? Контент ложится в кэш br, или в сыром виде и зажимается на лету? Можете посмотреть файл, просто грепните по ключу что используется в fastcgi_cache_key Например если у вас $http_host$uri и вы запросили https://site.address/ то ищется по nice sudo fgrep -ax 'KEY: site.address/' /path/to/nginx/cache -rl это даст название файла кэша в котором лежит https://site.address/ и который сможете открыть через less и посмотреть тело. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280218#msg-280218 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Dmytro Lavryk Wrote: --- > Собрал, включил, перезапустил. > Работает часа 3. Описаного эффекта не наблюдается - все работает. Точно зажимает? Попробуйте плиз на своем ресурсе запросить что-то по https. curl -H 'Accept-Encoding: br' -I https://example.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280212#msg-280212 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Отлключение компрессии brotli на лету решило проблему утечки FD: brotli off; Теперь осталось понять почему оно глючит. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280210#msg-280210 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Gena Makhomed Wrote: --- > On 20.06.2018 22:05, rihad wrote: > > > Brotli убрать к сожалению не вариант > > Довольно странное занятие для сервера - вытаскивать несжатые страницы > из кеша и потом тратить время и процессор сервера на компрессию > этих страниц новым и модным алгоритмом brotli. Да, знаю, на практике мизер по cpu из-за многоуровневного кэша. Вопрос даже не в этом, а в том, что: > > > Причем еще раз замечу что такой сетап работает без глюков с 1.12. > > Проблема явно не в nginx, а в этом стороннем модуле. > От этого ничуть не легче ( Т.к. в 1.12 вся эта связка не глючила с FD leak. Правда и archivers/brotli тоже обновился с 0.6.0 до 1.0.4 Лечишь секьюрные дырки (в данном случае обновление дыры libressl потребовало перестройки и обновления nginx) и вот такие скрытые дыры. > -- > Best regards, > Gena > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280209#msg-280209 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Dmytro Lavryk Wrote: --- > BROTLI off > > cache: > fastcgi_cache_path /var/tmp/nginx/fastcgi_cache levels=1:2 keys_zone= > ССС:100m inactive=240m; > > lsof +L1 | grep -w ^nginx | wc -l > 20 > > sysctl kern.openfiles > kern.openfiles: 3481 > > reload последний раз был не помню точно когда... как раз как версия > 1.14 в портах вышла - пересобрал и ребутнул. Brotli убрать к сожалению не вариант, да и зачем воркараундить, HTTP/2+Brotli, Accept-Encoding: br - норма в наши дни. Причем еще раз замечу что такой сетап работает без глюков с 1.12. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280202#msg-280202 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Илья Шипицин Wrote: --- > OPTIONS_FILE_SET+=BROTLI > > это недефолтная настройка ? Недефолтная. > > у нас примерно такой набор модулей. есть инсталяции на freebsd. > но кешем не пользуемся > > спецэффекта не наблюдаем > Потому что кешем не пользуетесь ) > > попробуйте на вашей сборке прогнать тесты вот эти > https://github.com/nginx/nginx-tests ? > А для чего? Одни конфиг, одни опции сборки, этого глюка нет на 1.12 и есть на 1.14. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280200#msg-280200 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Открытые файлы растут после обновления до 1.14
Вот на данный момент через 1 час 20 минут после последнего SIGHUP: $ sudo lsof +L1 | grep -w ^nginx | wc -l 39903 $ sysctl kern.openfiles kern.openfiles: 64706 (разницу можно игнорировать, там и postgres есть, я sysctl привел просто чтобы показать что они оба растут). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280197#msg-280197 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Открытые файлы растут после обновления до 1.14
После обновления nginx с 1.12 до 1.14 на FreeBSD 10 открытые удаленные файлы (lsof +L1) стремительно растут для nginx. В обеих версиях один конфиг, и одни опции постройки. OPTIONS_FILE_SET+=DSO OPTIONS_FILE_SET+=FILE_AIO OPTIONS_FILE_SET+=THREADS OPTIONS_FILE_SET+=HTTP OPTIONS_FILE_SET+=HTTP_CACHE OPTIONS_FILE_SET+=HTTP_GZIP_STATIC OPTIONS_FILE_SET+=HTTP_REALIP OPTIONS_FILE_SET+=HTTP_REWRITE OPTIONS_FILE_SET+=HTTP_SSL OPTIONS_FILE_SET+=HTTPV2 OPTIONS_FILE_SET+=STREAM_SSL_PREREAD OPTIONS_FILE_SET+=BROTLI Используется proxy_cache_path /usr/home/nginx/cache/foo/html levels=1:2 keys_zone=foo:64m inactive=1d max_size=8g; Единственный выход пока - периодически запускать service nginx reload (SIGHUP) - тогда старые воркеры отмирают и освобождают занятые дескрипторы. Есть еще сетапы с nginx 1.12 - там lsof +L1 тоже показывает такие файлы, но они измеряются в нескольких десятках и не растут. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280196#msg-280196 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
