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/