Re: Error log question

[Илья Шипицин]

ср, 27 июл. 2022 г. в 02:08, Maxim Dounin :

> Hello!
>
> On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote:
>
> > вт, 26 июл. 2022 г. в 19:33, Gena Makhomed :
> >
> > > On 26.07.2022 16:59, Maxim Dounin wrote:
> > >
> > >  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> > > allocate
> > >  >> new session in SSL session shared cache "le_nginx_SSL" while
> SSL
> > >  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> > >
> > > [...]
> > >
> > > >> Если не будет в логах ошибок - каким образом тогда пользователь
> > > >> сможет понять, что размер кэша для сессий SSL слишком маленький?
> > >
> > > > Точно так же, как и сейчас - по статистике повторного
> > > > использования сессий, других способов нет.  Обсуждаемое сообщение
> > > > об ошибке возникает тогда и только тогда, когда не удаётся
> > > > выделить память после удаления одной из старых сессий.  Такое
> > > > может происходить, например, если удалённая сессия заметно
> > > > отличается по размеру от создаваемой, и попадает в другой диапазон
> > > > выделений slab-аллокатора.
> > >
> > > А каким образом эту статистику повторного использования сессий
> > > можно получить? Для этого надо писать в лог значение переменной
> > > $ssl_session_reused потом скриптом вычислять процент запросов,
> > >
> >
> > и да, и нет. действительно, сессию можно логировать, но это не значит,
> что
> > сессия была использована.
> > сессии это устаревший механизм, сейчас 100% современных браузеров
> > используют tls tickets
>
> Когда я последний раз проверял (полгода назад в рамках ticket
> #1892, https://trac.nginx.org/nginx/ticket/1892) - в тикеты не
> умел Safari.
>
> Возможно, имеет смысл таки добраться до ticket #927
> (https://trac.nginx.org/nginx/ticket/927), и сделать, чтобы reuse
> сессий через тикеты можно было легко отличить от такового через
> кэш сессий.  Сейчас использование тикетов от кэша сессий
> отличается по отсутствию $ssl_session_id после первого хендшейка -
> что в принципе позволяет их отличать, но делать это, скажем так,
> неудобно.
>
> [...]
>
> > из того, с чем реально сталкивались - ротация тикетов и сессий. есть два
> > пограничных подхода
> >
> > а) никогда не делать релоад. (сессии вечные, безопасники несчастны)
> > б) иногда делать релоад. сессии ротируются, но по вам со всей дури
> > прилетает cpu storm на полных хендшейках
> >
> > как-то управляемо ротировать сессии, без привязки к релоаду, было бы
> > идеально
>
> Проблема не в "сессии вечные", проблема, о которой любят плакаться
> безопасники - это то, что ключ шифрования тикетов меняется только
> при релоаде.  Соответственно если кто-нибудь сможет получить этот
> ключ - он сможет расшифровать записанный трафик после последнего
> релоада.  Ключ - симметричный ключ на 256-бит, то есть
> единственная реальная возможность его получить - это доступ к
> оперативной памяти работающего сервера.
>
> Если это действительно проблема, то сейчас есть два работающих
> варианта её решения, не приводящих к увеличению числа полных
> хендшейков:
>
> - Выключить тикеты, и использовать кэш сессий.  В этом случае
>   сессионные ключи будут удаляться из памяти сервера по мере
>   перезаписи другими сессиями, и соответственно возможность
>   расшифровки ранее записанного трафика ограничена последними
>   сессиями.
>
> - Использовать несколько ключей для шифрования тикетов, заданных
>   через директиву ssl_session_ticket_key, и периодически их
>   вращать (добавлять новый и убирать самый старый).  В этом случае
>   ключи для шифрования тикетов обновляются с любой удобной частотой,
>   а количество полных хендшейков не увеличивается (так как для
>   шифрования новых тикетов используется первый ключ, и старые ключи
>   становятся не нужны после истечения ssl_session_timeout с того
>   момента, как ключ перестал быть первым).
>

я почему-то был уверен, что ключ может быть только один.
надо будет затестить несколько ключей


>
> В планах - сделать-таки автоматическое вращение ключей в памяти,
> но пока этого нет.  В частности потому, что модель угроз, в
> которой это важно - выглядит немного оторванной от реальности.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Maxim Dounin]

Hello!

On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote:

> вт, 26 июл. 2022 г. в 19:33, Gena Makhomed :
> 
> > On 26.07.2022 16:59, Maxim Dounin wrote:
> >
> >  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> > allocate
> >  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
> >  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> >
> > [...]
> >
> > >> Если не будет в логах ошибок - каким образом тогда пользователь
> > >> сможет понять, что размер кэша для сессий SSL слишком маленький?
> >
> > > Точно так же, как и сейчас - по статистике повторного
> > > использования сессий, других способов нет.  Обсуждаемое сообщение
> > > об ошибке возникает тогда и только тогда, когда не удаётся
> > > выделить память после удаления одной из старых сессий.  Такое
> > > может происходить, например, если удалённая сессия заметно
> > > отличается по размеру от создаваемой, и попадает в другой диапазон
> > > выделений slab-аллокатора.
> >
> > А каким образом эту статистику повторного использования сессий
> > можно получить? Для этого надо писать в лог значение переменной
> > $ssl_session_reused потом скриптом вычислять процент запросов,
> >
> 
> и да, и нет. действительно, сессию можно логировать, но это не значит, что
> сессия была использована.
> сессии это устаревший механизм, сейчас 100% современных браузеров
> используют tls tickets

Когда я последний раз проверял (полгода назад в рамках ticket 
#1892, https://trac.nginx.org/nginx/ticket/1892) - в тикеты не 
умел Safari.

Возможно, имеет смысл таки добраться до ticket #927 
(https://trac.nginx.org/nginx/ticket/927), и сделать, чтобы reuse 
сессий через тикеты можно было легко отличить от такового через 
кэш сессий.  Сейчас использование тикетов от кэша сессий 
отличается по отсутствию $ssl_session_id после первого хендшейка - 
что в принципе позволяет их отличать, но делать это, скажем так, 
неудобно.

[...]

> из того, с чем реально сталкивались - ротация тикетов и сессий. есть два
> пограничных подхода
> 
> а) никогда не делать релоад. (сессии вечные, безопасники несчастны)
> б) иногда делать релоад. сессии ротируются, но по вам со всей дури
> прилетает cpu storm на полных хендшейках
> 
> как-то управляемо ротировать сессии, без привязки к релоаду, было бы
> идеально

Проблема не в "сессии вечные", проблема, о которой любят плакаться 
безопасники - это то, что ключ шифрования тикетов меняется только 
при релоаде.  Соответственно если кто-нибудь сможет получить этот 
ключ - он сможет расшифровать записанный трафик после последнего 
релоада.  Ключ - симметричный ключ на 256-бит, то есть 
единственная реальная возможность его получить - это доступ к 
оперативной памяти работающего сервера.

Если это действительно проблема, то сейчас есть два работающих 
варианта её решения, не приводящих к увеличению числа полных 
хендшейков:

- Выключить тикеты, и использовать кэш сессий.  В этом случае 
  сессионные ключи будут удаляться из памяти сервера по мере 
  перезаписи другими сессиями, и соответственно возможность 
  расшифровки ранее записанного трафика ограничена последними 
  сессиями.

- Использовать несколько ключей для шифрования тикетов, заданных 
  через директиву ssl_session_ticket_key, и периодически их 
  вращать (добавлять новый и убирать самый старый).  В этом случае 
  ключи для шифрования тикетов обновляются с любой удобной частотой, 
  а количество полных хендшейков не увеличивается (так как для 
  шифрования новых тикетов используется первый ключ, и старые ключи 
  становятся не нужны после истечения ssl_session_timeout с того 
  момента, как ключ перестал быть первым).

В планах - сделать-таки автоматическое вращение ключей в памяти, 
но пока этого нет.  В частности потому, что модель угроз, в 
которой это важно - выглядит немного оторванной от реальности.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Илья Шипицин]

вт, 26 июл. 2022 г. в 19:33, Gena Makhomed :

> On 26.07.2022 16:59, Maxim Dounin wrote:
>
>  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> allocate
>  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
>  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
>
> [...]
>
> >> Если не будет в логах ошибок - каким образом тогда пользователь
> >> сможет понять, что размер кэша для сессий SSL слишком маленький?
>
> > Точно так же, как и сейчас - по статистике повторного
> > использования сессий, других способов нет.  Обсуждаемое сообщение
> > об ошибке возникает тогда и только тогда, когда не удаётся
> > выделить память после удаления одной из старых сессий.  Такое
> > может происходить, например, если удалённая сессия заметно
> > отличается по размеру от создаваемой, и попадает в другой диапазон
> > выделений slab-аллокатора.
>
> А каким образом эту статистику повторного использования сессий
> можно получить? Для этого надо писать в лог значение переменной
> $ssl_session_reused потом скриптом вычислять процент запросов,
> у которых $ssl_session_reused возвращает значение "r" ? И в том случае,
>

подобные штуки можно логировать в nginx-lua
(модуль не всеми считается production ready, ваше использование его
предполагает осознанный выбор)

в log_by_lua добавить обработчик, который в зависимости от
$ssl_session_reused будет увеличивать
счетчик общих запросов и счетчик кешированных

Lua Ngx API - OpenResty Reference (openresty-reference.readthedocs.io)


и в каком-нибудь локейшене через content_by_lua отдавать эти счетчики

правда, с релоадом счетчики обнулятся


> если этот процент стал меньше обычно наблюдаемого значения -
> это будет означать, что размер кэша для сессий SSL
> возможно стал слишком мал и его желательно увеличить?
>
> --
> Best regards,
>   Gena
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Илья Шипицин]

вт, 26 июл. 2022 г. в 19:33, Gena Makhomed :

> On 26.07.2022 16:59, Maxim Dounin wrote:
>
>  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> allocate
>  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
>  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
>
> [...]
>
> >> Если не будет в логах ошибок - каким образом тогда пользователь
> >> сможет понять, что размер кэша для сессий SSL слишком маленький?
>
> > Точно так же, как и сейчас - по статистике повторного
> > использования сессий, других способов нет.  Обсуждаемое сообщение
> > об ошибке возникает тогда и только тогда, когда не удаётся
> > выделить память после удаления одной из старых сессий.  Такое
> > может происходить, например, если удалённая сессия заметно
> > отличается по размеру от создаваемой, и попадает в другой диапазон
> > выделений slab-аллокатора.
>
> А каким образом эту статистику повторного использования сессий
> можно получить? Для этого надо писать в лог значение переменной
> $ssl_session_reused потом скриптом вычислять процент запросов,
>

и да, и нет. действительно, сессию можно логировать, но это не значит, что
сессия была использована.
сессии это устаревший механизм, сейчас 100% современных браузеров
используют tls tickets

SSL session tickets vs session ids - Stack Overflow


это примерно как сессии, но хранятся на клиенте.



> у которых $ssl_session_reused возвращает значение "r" ? И в том случае,
> если этот процент стал меньше обычно наблюдаемого значения -
>

вопрос хороший, но, не уверен, что актуальный.

из того, с чем реально сталкивались - ротация тикетов и сессий. есть два
пограничных подхода

а) никогда не делать релоад. (сессии вечные, безопасники несчастны)
б) иногда делать релоад. сессии ротируются, но по вам со всей дури
прилетает cpu storm на полных хендшейках

как-то управляемо ротировать сессии, без привязки к релоаду, было бы
идеально


> это будет означать, что размер кэша для сессий SSL
> возможно стал слишком мал и его желательно увеличить?
>
> --
> Best regards,
>   Gena
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Gena Makhomed]

On 26.07.2022 16:59, Maxim Dounin wrote:


>> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
>> new session in SSL session shared cache "le_nginx_SSL" while SSL
>> handshaking, client: 175.156.80.121, server: 0.0.0.0:443


[...]


Если не будет в логах ошибок - каким образом тогда пользователь
сможет понять, что размер кэша для сессий SSL слишком маленький?



Точно так же, как и сейчас - по статистике повторного
использования сессий, других способов нет.  Обсуждаемое сообщение
об ошибке возникает тогда и только тогда, когда не удаётся
выделить память после удаления одной из старых сессий.  Такое
может происходить, например, если удалённая сессия заметно
отличается по размеру от создаваемой, и попадает в другой диапазон
выделений slab-аллокатора.


А каким образом эту статистику повторного использования сессий
можно получить? Для этого надо писать в лог значение переменной
$ssl_session_reused потом скриптом вычислять процент запросов,
у которых $ssl_session_reused возвращает значение "r" ? И в том случае,
если этот процент стал меньше обычно наблюдаемого значения -
это будет означать, что размер кэша для сессий SSL
возможно стал слишком мал и его желательно увеличить?

--
Best regards,
 Gena
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Maxim Dounin]

Hello!

On Tue, Jul 26, 2022 at 02:54:36PM +0300, Gena Makhomed wrote:

> On 26.07.2022 0:34, Maxim Dounin wrote:
> 
> >>   >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
> >>   >> new session in SSL session shared cache "le_nginx_SSL" while SSL
> >>   >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> >>   >
> >>   > This error indicate that nginx wasn't able to allocate new session
> >>   > in the SSL session cache defined by the "ssl_session_cache"
> >>   > directive, and removing an old session didn't help.  This
> >>   > basically indicate that the SSL session cache is too small, and it
> >>   > would be a good idea to either configure a larger cache or reduce
> >>   > ssl_session_timeout.  The logging level is probably a bit too
> >>   > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
> >>
> >> Максим, Вы говорите, что "The message is probably a bit too scary
> >> (while the situation itself is mostly harmless)".
> >>
> >> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
> >>
> >> Разве не проще один раз пофиксить эту проблему в исходниках nginx,
> >> чем постоянно рассказывать пользователям в списках рассылки о том,
> >> что "The logging level is probably a bit too scary"?
> >>
> >> Если просто поменять [alert] на [warn] - ничего ведь не сломается?
> >> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.
> > 
> > По конкретному тикету есть несколько моментов:
> > 
> > - Перед тем, как менять уровень логгирования - надо как минимум
> >проверить, что в случае невозможности выделения памяти для сессии
> >действительно ничего не ломается.
> > 
> > - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
> >смысла изменить логику удаления старых сессий в случае нехватки
> >памяти, чтобы ошибок не возникало.  Или даже переделать логику
> >выделения памяти под сессии, дабы минимизировать вероятность
> >неуспеха.  Или прикрутить логику, аналогичную реализованной для
> >памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).
> 
> Если не будет в логах ошибок - каким образом тогда пользователь
> сможет понять, что размер кэша для сессий SSL слишком маленький?

Точно так же, как и сейчас - по статистике повторного 
использования сессий, других способов нет.  Обсуждаемое сообщение 
об ошибке возникает тогда и только тогда, когда не удаётся 
выделить память после удаления одной из старых сессий.  Такое 
может происходить, например, если удалённая сессия заметно 
отличается по размеру от создаваемой, и попадает в другой диапазон 
выделений slab-аллокатора.

[...]

> Этот список рассылки, nginx-ru наверное не очень подходит
> для обсуждения NGINX Amplify Agent и NGINX Amplify?

Совершенно не подходит.  Впрочем, не уверен, что подходящее место 
вообще существует.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Gena Makhomed]

On 26.07.2022 0:34, Maxim Dounin wrote:


  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
  >
  > This error indicate that nginx wasn't able to allocate new session
  > in the SSL session cache defined by the "ssl_session_cache"
  > directive, and removing an old session didn't help.  This
  > basically indicate that the SSL session cache is too small, and it
  > would be a good idea to either configure a larger cache or reduce
  > ssl_session_timeout.  The logging level is probably a bit too
  > scary, see https://trac.nginx.org/nginx/ticket/621 for details.

Максим, Вы говорите, что "The message is probably a bit too scary
(while the situation itself is mostly harmless)".

Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.

Разве не проще один раз пофиксить эту проблему в исходниках nginx,
чем постоянно рассказывать пользователям в списках рассылки о том,
что "The logging level is probably a bit too scary"?

Если просто поменять [alert] на [warn] - ничего ведь не сломается?
Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.


По конкретному тикету есть несколько моментов:

- Перед тем, как менять уровень логгирования - надо как минимум
   проверить, что в случае невозможности выделения памяти для сессии
   действительно ничего не ломается.

- А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
   смысла изменить логику удаления старых сессий в случае нехватки
   памяти, чтобы ошибок не возникало.  Или даже переделать логику
   выделения памяти под сессии, дабы минимизировать вероятность
   неуспеха.  Или прикрутить логику, аналогичную реализованной для
   памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).


Если не будет в логах ошибок - каким образом тогда пользователь
сможет понять, что размер кэша для сессий SSL слишком маленький?

Может же быть так, что установлен размер кэша для примерно 4000 сессий,
а активных клиентов будет примерно в десять раз больше - в этом случае
nginx будет постоянно удалять "старые" сессии, ничего при этом в логах
не сообщая пользователю. Наверное это не самый лучший вариант поведения?

Или наоборот, когда выставлен очень большой размер для кэша сессий SSL,
а используется не более 10% - это тоже неоптимальная настройка nginx.

Пользователи nginx-plus наверное смогут установить на свои сервера
nginx-amplify-agent и возможно смогут увидеть в NGINX Amplify,
что кэш для сессий SSL переполнен и его следует увеличить. (?)

Но что в таком случае делать пользователям open source версии nginx?
Насколько я понимаю, в NGINX Amplify для open source версии nginx
метрик для кэша сессий SSL нет.

Особенно, если пользователи nginx используют Rocky Linux 8.6,
при запуске скрипта install.sh выдается такое сообщение про ошибку:
Checking OS compatibility ... rocky is currently unsupported, apologies!
Хотя по своей сути Rocky Linux 8.6 ведь ничем не отличается от RHEL 8.6.
Это же 1:1 бинарно совместимая с RHEL8 сборка EL8 из тех же исходников.

Если вручную прописать в файле /etc/yum.repos.d/nginx-amplify.repo

[nginx-amplify]
name=nginx amplify repo
baseurl=http://packages.amplify.nginx.com/py3/rhel/8/$basearch
gpgcheck=1
enabled=1

В таком случае NGINX Amplify Agent нормально устанавливается
на Rocky Linux 8.6 и даже нормально запускается.

Этот список рассылки, nginx-ru наверное не очень подходит
для обсуждения NGINX Amplify Agent и NGINX Amplify?

Куда лучше всего будет писать bug reports и feature requests
по NGINX Amplify Agent и NGINX Amplify, напрямую емейлом разработчикам?

--
Best regards,
 Gena
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Илья Шипицин]

вт, 26 июл. 2022 г. в 02:35, Maxim Dounin :

> Hello!
>
> On Mon, Jul 25, 2022 at 11:05:56AM +0300, Gena Makhomed wrote:
>
> > On 24.07.2022 1:15, Maxim Dounin wrote:
> >
> >  >> My nginx error log is being filled with errors which I believe are
> being
> >  >> surfaced from OpenSSL. The log entries number in the hundreds of
> >  >> thousands per day and I understand they are most likely due to
> >  >> conditions beyond my control. Examples of the log entries are:
> >
> > [...]
> >
> >  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> allocate
> >  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
> >  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> >  >
> >  > This error indicate that nginx wasn't able to allocate new session
> >  > in the SSL session cache defined by the "ssl_session_cache"
> >  > directive, and removing an old session didn't help.  This
> >  > basically indicate that the SSL session cache is too small, and it
> >  > would be a good idea to either configure a larger cache or reduce
> >  > ssl_session_timeout.  The logging level is probably a bit too
> >  > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
> >
> > Максим, Вы говорите, что "The message is probably a bit too scary
> > (while the situation itself is mostly harmless)".
> >
> > Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
> >
> > Разве не проще один раз пофиксить эту проблему в исходниках nginx,
> > чем постоянно рассказывать пользователям в списках рассылки о том,
> > что "The logging level is probably a bit too scary"?
> >
> > Если просто поменять [alert] на [warn] - ничего ведь не сломается?
> > Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.
>
> По конкретному тикету есть несколько моментов:
>
> - Перед тем, как менять уровень логгирования - надо как минимум
>   проверить, что в случае невозможности выделения памяти для сессии
>   действительно ничего не ломается.
>

можно, наверное, поменять alert на warn, а потом еще лет 8 исследовать
описанные моменты, которые действительно требуют время


>
> - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
>   смысла изменить логику удаления старых сессий в случае нехватки
>   памяти, чтобы ошибок не возникало.  Или даже переделать логику
>   выделения памяти под сессии, дабы минимизировать вероятность
>   неуспеха.  Или прикрутить логику, аналогичную реализованной для
>   памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).
>
> Всё это требует времени, которое конечно.
>
> Кроме того, "постоянно рассказывать" - на моей памяти примерно
> первый раз за прошедшие с момента появления этого тикета 8 лет.
> То есть проблемы, фактически, нет.
>
> > Сейчас в nginx trac открыто 263 тикета
> > https://trac.nginx.org/nginx/report/1
> > разве не было бы логично уменьшить их количество
> > до минимально возможного числа, в идеале - до нуля?
>
> Было бы логично, конечно.  Лично я регулярно занимаюсь тем, что
> уменьшаю количество открытых тикетов.  Открытых тикетов про
> проблемы в коде сейчас - 70 штук, большую часть просто так не
> закрыть.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Maxim Dounin]

Hello!

On Mon, Jul 25, 2022 at 11:05:56AM +0300, Gena Makhomed wrote:

> On 24.07.2022 1:15, Maxim Dounin wrote:
> 
>  >> My nginx error log is being filled with errors which I believe are being
>  >> surfaced from OpenSSL. The log entries number in the hundreds of
>  >> thousands per day and I understand they are most likely due to
>  >> conditions beyond my control. Examples of the log entries are:
> 
> [...]
> 
>  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
>  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
>  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
>  >
>  > This error indicate that nginx wasn't able to allocate new session
>  > in the SSL session cache defined by the "ssl_session_cache"
>  > directive, and removing an old session didn't help.  This
>  > basically indicate that the SSL session cache is too small, and it
>  > would be a good idea to either configure a larger cache or reduce
>  > ssl_session_timeout.  The logging level is probably a bit too
>  > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
> 
> Максим, Вы говорите, что "The message is probably a bit too scary
> (while the situation itself is mostly harmless)".
> 
> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
> 
> Разве не проще один раз пофиксить эту проблему в исходниках nginx,
> чем постоянно рассказывать пользователям в списках рассылки о том,
> что "The logging level is probably a bit too scary"?
> 
> Если просто поменять [alert] на [warn] - ничего ведь не сломается?
> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.

По конкретному тикету есть несколько моментов:

- Перед тем, как менять уровень логгирования - надо как минимум 
  проверить, что в случае невозможности выделения памяти для сессии 
  действительно ничего не ломается.

- А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли 
  смысла изменить логику удаления старых сессий в случае нехватки 
  памяти, чтобы ошибок не возникало.  Или даже переделать логику 
  выделения памяти под сессии, дабы минимизировать вероятность 
  неуспеха.  Или прикрутить логику, аналогичную реализованной для 
  памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).

Всё это требует времени, которое конечно.

Кроме того, "постоянно рассказывать" - на моей памяти примерно 
первый раз за прошедшие с момента появления этого тикета 8 лет.  
То есть проблемы, фактически, нет.

> Сейчас в nginx trac открыто 263 тикета
> https://trac.nginx.org/nginx/report/1
> разве не было бы логично уменьшить их количество
> до минимально возможного числа, в идеале - до нуля?

Было бы логично, конечно.  Лично я регулярно занимаюсь тем, что 
уменьшаю количество открытых тикетов.  Открытых тикетов про 
проблемы в коде сейчас - 70 штук, большую часть просто так не 
закрыть.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Gena Makhomed]

On 24.07.2022 1:15, Maxim Dounin wrote:

>> My nginx error log is being filled with errors which I believe are being
>> surfaced from OpenSSL. The log entries number in the hundreds of
>> thousands per day and I understand they are most likely due to
>> conditions beyond my control. Examples of the log entries are:

[...]

>> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
>> new session in SSL session shared cache "le_nginx_SSL" while SSL
>> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
>
> This error indicate that nginx wasn't able to allocate new session
> in the SSL session cache defined by the "ssl_session_cache"
> directive, and removing an old session didn't help.  This
> basically indicate that the SSL session cache is too small, and it
> would be a good idea to either configure a larger cache or reduce
> ssl_session_timeout.  The logging level is probably a bit too
> scary, see https://trac.nginx.org/nginx/ticket/621 for details.

Максим, Вы говорите, что "The message is probably a bit too scary
(while the situation itself is mostly harmless)".

Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.

Разве не проще один раз пофиксить эту проблему в исходниках nginx,
чем постоянно рассказывать пользователям в списках рассылки о том,
что "The logging level is probably a bit too scary"?

Если просто поменять [alert] на [warn] - ничего ведь не сломается?
Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.

Сейчас в nginx trac открыто 263 тикета
https://trac.nginx.org/nginx/report/1
разве не было бы логично уменьшить их количество
до минимально возможного числа, в идеале - до нуля?

--
Best regards,
 Gena
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org