Журналы ошибок заполняются записями Client AH02027/AH2026: Не удалось освободить блокировку кэша SSL-сессии.

Вопрос или проблема

Мой error_log заполняется множеством записей такого вида:

www.mine.com [Sun Dec 29 09:29:59 2024] [warn] [pid 903933] ssl_engine_mutex.c(105): (22)Invalid argument: [client AH02027: Failed to release SSL session cache lock
www.mine.com [Sun Dec 29 09:30:00 2024] [warn] [pid 1177911] ssl_engine_mutex.c(92): (22)Invalid argument: [client AH02026: Failed to acquire SSL session cache lock
www.mine.com [Sun Dec 29 09:30:00 2024] [warn] [pid 1177911] ssl_engine_mutex.c(105): (22)Invalid argument: [client AH02027: Failed to release SSL session cache lock
www.mine.com [Sun Dec 29 09:30:00 2024] [warn] [pid 1177911] ssl_engine_mutex.c(92): (22)Invalid argument: [client AH02026: Failed to acquire SSL session cache lock
www.mine.com [Sun Dec 29 09:30:00 2024] [warn] [pid 1177911] ssl_engine_mutex.c(105): (22)Invalid argument: [client AH02027: Failed to release SSL session cache lock

Хост решил это сначала следующим образом:

Я установил следующую опцию в вашем MySQL конфигурационном файле:

log_warnings = 0

Это предотвратит логирование предупреждений, но не повлияет на
обычное логирование ошибок.

Но после очередного обновления MySQL они заявили:

Эта проблема должна быть решена теперь. Проблема заключалась в том, что старый параметр, использованный для
подавления этих сообщений “log_warnings”, был устаревшим в версии 5.7 и удален в
mySQL 8.0. Я обновил конфигурационный файл с новым директивой mySQL ниже.

log_error_verbosity = 1

Это приведет к тем же результатам: предупреждения будут подавлены, и
только реальные ошибки будут записываться в журнал.

Это не сработало, поэтому они ответили:

Наш ведущий системный администратор изучил вопрос, и, к сожалению, не смог
найти способ подавить эти предупреждения, так что боюсь, это
“нормально” для всех намерений и целей.

Они предоставили дополнительную информацию:

Единственное значение mutex, установленное в активных конфигурационных
файлах Apache, следующее:

Mutex default:/usr/nobody

‘DUMP_RUN_CFG’ возвращает следующие значения mutex:

Mutex default: dir=”/usr/nobody” mechanism=default Mutex
ssl-cache: using_defaults Mutex mpm-accept: using_defaults Mutex
authdigest-opaque: using_defaults Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults Mutex authdigest-client:
using_defaults Mutex ssl-stapling: using_defaults Mutex proxy:
using_defaults

Существовала зарегистрированная ошибка, вызывавшая эту проблему в более ранних
версиях Ubuntu + Apache, таких как:

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1565744

но в тех случаях механизм mutex, возвращаемый ‘DUMP_RUN_CFG’, был:

mechanism=fcntl

и мы не смогли найти ничего, относящегося к версии
Apache, работающей на вашем сервере (2.4.62).

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

Заранее спасибо!!

Ответ или решение

Ваши журналы ошибок Apache заполняются записями, связанными с проблемами блокировки кеша SSL-сеансов, что может быть вызвано конфликтами в настройках блокировок (мьютексов) или устаревшими конфигурациями. Давайте рассмотрим возможности решения этой проблемы.

1. Анализ проблемы

Записи, которые вы видите, связаны с неудачей захвата или освобождения блокировки кеша SSL-сеанса. Это может указывать на следующие проблемы:

  • Неудачные механизмы блокировки: Используемый механизм блокировки может быть несовместим с вашей текущей системой.
  • Недостаток прав или неисправная конфигурация файловой системы: Могут возникать проблемы с правами доступа к каталогу, используемому для хранения временных файлов мьютексов.
  • Программные ошибки Apache: Иногда обновления программного обеспечения или несоответствующая конфигурация могут вызывать такие логгируемые ошибки.

2. Решения

Проверка конфигурации мьютексов

  1. Проверьте настройки мьютексов в конфигурационном файле Apache:

    • Используйте директиву Mutex для явного указания механизма и каталога.
    • Попробуйте использовать механизм pthread или sysvsem, если существует подозрение на проблему с системой файлов.
  2. Права доступа и местоположение:

    • Проверьте, что каталог /usr/nobody имеет правильные права на чтение/запись для пользователя, под которым работает Apache.
    • Попробуйте изменить каталог на /var/lock/apache2 или другой подходящий и доступный каталог.

Обновление и устранение неисправностей

  1. Обновление системы:

    • Убедитесь, что все компоненты системы, такие как OpenSSL, Apache и операционная система, обновлены до последней версии, поскольку некоторые проблемы могут быть уже устранены.
  2. Мониторинг процессов:

    • Проверьте, нет ли конфликта процессов или нехватки ресурсов, используя утилиты мониторинга, такие как top, htop, или lsof.
  3. Журналирование:

    • Понизьте уровень регистрации ошибок SSL до критического (если это не критично для вашего бизнеса) с помощью директивы: LogLevel ssl:crit, чтобы уменьшить число логгируемых предупреждений.
  4. Проверка сбоев в обработке событий:

    • Используйте утилиту strace для отслеживания системных вызовов и сигналов, которые может использовать Apache для работы с мьютексами.

3. Альтернативные пути

Обеспечьте резервное копирование текущей конфигурации и проведите тестирование на тестовом сервере перед внесением серьезных изменений в производственную среду.

Если приведенные шаги не решат проблему, рекомендуется обратиться к экспертам в области системного администрирования или поддержке Apache для более углубленной диагностики.

Заключение

Систематическая проверка и оптимизация настройки мьютексов в Apache может решить проблему излишней регистрации ошибок. Ваша задача — устранить источники ошибки, обеспечив стабильность и производительность системы. Благодаря внимательному отношению к деталям конфигурации и регулярным обновлениям ПО, такие проблемы можно минимизировать и избежать в будущем.

Оцените материал
Добавить комментарий

Капча загружается...