Вопрос или проблема
Это странный случай, у меня есть собранный вручную apache 2.4 на старом сервере CentOS 8, и я наблюдаю странное поведение во время загрузки.
У меня есть файл службы systemd :
[Unit]
Description=Apache 2.4 для Moodle
After=network.target
[Service]
Type=forking
#Type=notify
ExecStart=/usr/local/apache/2.4/bin/apachectl start
ExecStop=/usr/local/apache/2.4/bin/apachectl stop
ExecReload=/usr/local/apache/2.4/bin/apachectl restart
[Install]
WantedBy=multi-user.target
и если я запускаю systemctl start|restart moodleapache, всё работает нормально.
НО
Если я перезагружаю сервер, хотя httpd явно работает (он в таблице процессов), я получаю странную ошибку SSL в браузере :
Безопасное соединение не удалось
Произошла ошибка во время соединения с blahblah.somewhere. SSL
получил запись, которая превышала максимальную допустимую длину.
Код ошибки: SSL_ERROR_RX_RECORD_TOO_LONG
Страницу, которую вы пытаетесь просмотреть, нельзя отобразить, потому что достоверность полученных данных не может быть проверена.
Пожалуйста, свяжитесь с владельцами сайта, чтобы сообщить им об этой проблеме.
Apache работает прекрасно :
ps -ef | grep http
root 1087 1 0 13:15 ? 00:00:00 /usr/local/apache/2.4/bin/httpd -k start
apache 1104 1087 0 13:15 ? 00:00:00 /usr/local/apache/2.4/bin/httpd -k start
apache 1105 1087 0 13:15 ? 00:00:00 /usr/local/apache/2.4/bin/httpd -k start
apache 1106 1087 0 13:15 ? 00:00:00 /usr/local/apache/2.4/bin/httpd -k start
и он слушает на 80 и 443 :
[carl@avmoodle ~]$ netstat -an | grep 80 | grep LIST
tcp6 0 0 :::80 :::* LISTEN
[carl@avmoodle ~]$ netstat -an | grep 443 | grep LIST
tcp6 0 0 :::443 :::* LISTEN
Хотя интересно, не на IPv4
Я вижу то же самое после systemctl restart moodleapache :
[root@avmoodle ~]# netstat -an | grep 80 | grep LIST
tcp6 0 0 :::80 :::* LISTEN
[root@avmoodle ~]# netstat -an | grep 443 | grep LIST
tcp6 0 0 :::443 :::* LISTEN
Кроме того, теперь ошибка SSL исчезла, и сайт работает нормально.
Это немного ставит меня в тупик. Я всегда могу запустить apache вручную после перезагрузки, но что-то не так. SELinux отключен, так что это не оно :
avmoodle ~]# sestatus
Статус SELinux: отключен
э… Есть идеи? Я пропустил какую-то зависимость в своем .service файле?
В логах apache нет ничего интересного, чтобы сказать мне, что происходит
@avmoodle logs]# more error_log
[Пт Дек 13 13:14:44.270580 2024] [mpm_event:notice] [pid 3942:tid 3942] AH00491: пойман SIGTERM, завершение работы
[Пт Дек 13 13:15:02.964278 2024] [mpm_event:notice] [pid 1087:tid 1087] AH00489: Apache/2.4.62 (Unix) OpenSSL/1.1.1k PHP/8.2.26 сконфигурирован -
- продолжаем обычные операции
[Пт Дек 13 13:15:02.988008 2024] [core:notice] [pid 1087:tid 1087] AH00094: Команда: '/usr/local/apache/2.4/bin/httpd'
[Пт Дек 13 13:20:26.006680 2024] [mpm_event:notice] [pid 1087:tid 1087] AH00491: пойман SIGTERM, завершение работы
[Пт Дек 13 13:20:26.092544 2024] [mpm_event:notice] [pid 4001:tid 4001] AH00489: Apache/2.4.62 (Unix) OpenSSL/1.1.1k PHP/8.2.26 сконфигурирован -
- продолжаем обычные операции
[Пт Дек 13 13:20:26.092580 2024] [core:notice] [pid 4001:tid 4001] AH00094: Команда: '/usr/local/apache/2.4/bin/httpd'
и другие логи пустые.
Мне интересно, может быть, это проблема urandom? Какой-то другой временной вопрос?
Есть какие-нибудь предложения?
Ответ или решение
Ошибка SSL Apache после загрузки системы: возможные причины и пути решения
В вашем случае наблюдается интересная ситуация, когда Apache запускается без ошибок после перезагрузки, но возникла ошибка SSL, которая исчезает после ручного перезапуска службы. Это может быть связано с несколькими факторами, включая порядок инициализации сервисов и задержку в предоставлении необходимых ресурсов.
1. Последовательность загрузки сервисов
Убедитесь, что в вашем файле службы указаны правильные зависимости. Например, отсутствует зависимость от ssl-cert или других компонентов, необходимых для корректной работы SSL. Добавьте следующую строку в секцию [Unit]:
Requires=network-online.target
After=network-online.targetЭто гарантирует, что сеть полностью инициализирована перед запуском Apache.
2. Параметры конфигурации Apache
Также стоит взглянуть на конфигурацию SSL, находящуюся в файле конфигурации вашего виртуального хоста. Убедитесь, что все пути к сертификатам и ключам заданы правильно и доступ к ним есть на момент запуска службы.
SSLCertificateFile "/path/to/your/certificate.pem"
SSLCertificateKeyFile "/path/to/your/private-key.pem"3. Проверка сертификатов
Иногда причина кроется в том, что Apache не может получить необходимые криптографические параметры сразу после загрузки, потому что /dev/urandom может работать медленно на старых системах. Попробуйте заменить используемый источник случайных чисел. Убедитесь, что все используемые сертификаты действительны и корректно настроены.
4. Логи и их анализ
Изучите логи Apache более подробно. Возможно, в них скрыты важные подсказки. Обратите внимание на ssl_error_log, если таковой существует. Вы можете настроить уровень ведения логов, добавив следующую строку в конфигурацию Apache:
LogLevel ssl:debug5. Альтернативные версии OpenSSL
Если проблема не исчезнет, попытайтесь обновить или сменить версию OpenSSL. Иногда обновление OpenSSL решает совместимые проблемы, которые могут вызывать сбои в работе SSL.
6. Внедрение стартового скрипта
Как временное решение, вы можете добавить в ваш файл службы скрипт, который будет ожидать несколько секунд перед запуском Apache, что позволит системе завершить загрузку всех необходимых ресурсов:
[Service]
ExecStartPre=/bin/sleep 10Заключение
Проблема, с которой вы столкнулись, может иметь несколько причин, связанных с зависимостями или инициализацией службы. Правильная настройка зависимости в вашем файле службы и анализ логов должны помочь в диагностике и устранении проблемы. Убедитесь, что все необходимые компоненты и сертификаты доступны на момент инициализации Apache. Подходите к ситуации с терпением и методично исследуйте каждый аспект. Удачи в решении вашей проблемы!