polyanin
@polyanin
Golang, PHP & Symfony developer

Почему не стартует php7.2-fpm после ребута?

service php7.2-fpm status
● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Sun 2018-01-28 05:08:57 +05; 1min 36s ago
Docs: man:php-fpm7.2(8)
Process: 434 ExecStart=/usr/sbin/php-fpm7.2 --nodaemonize --fpm-config /etc/php/7.2/fpm/php-fpm.conf (code=killed, signal=TERM)
Main PID: 434 (code=killed, signal=TERM)

Jan 28 05:07:26 vm-83a6fe5c systemd[1]: Starting The PHP 7.2 FastCGI Process Manager...
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Start operation timed out. Terminating.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: Failed to start The PHP 7.2 FastCGI Process Manager.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Unit entered failed state.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Failed with result 'timeout'.
  • Вопрос задан
  • 6612 просмотров
Решения вопроса 1
scukokot
@scukokot
Работаю в netangels.ru
Александр Владимирович, давайте поясню, раз не только у вас такая штука, как наблюдаю в комментариях.

Более полное описание ситуации: проблема есть только при старте системы. Если перезапустить сервис на работающей машине все достаточно быстро поднимается.

Пример как отлавливать баги в случае старта сервисов из под systemd:

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

ExecStart=/usr/bin/strace -f -ff -tt -o /tmp/strace.log <Оригинальная команда запуска сервиса>

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

Далее конкретно про наш случай.

Выполнение команды запуска ломается на запросе getrandom. Если выставить задержку старта процесса, то данный запрос отрабатывает. При этом, чем дальше отложить старт сервиса, тем быстрее он работает.

Данный вызов напрямую связан с системными вызовами random/urandom и количеством энтропии в системе. Очевидно, что от времени старта работа системных вызовов не должна меняться, хотя и стоит проверить последовательность старта сервисов в systemd. Значит это энтропия.
На старте смотрим количество

# cat /proc/sys/kernel/random/entropy_avail

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

Выдержка из статьи на тему энтропии:
Linux уже предоставляет довольно качественные случайные данные при помощи вышеописанного ПО, но поскольку автономные компьютеры обычно не имеют клавиатуры или мыши, генерируемая на них энтропия гораздо ниже, поскольку создаётся диском или I/O сети. Очень немногие автономные машины имеют специальное аппаратное обеспечение для ГСЧ, поэтому существует несколько пользовательских решений для создания дополнительной энтропии при помощи аппаратных прерываний, т.к. некоторые устройства (например, звуковые и видеокарты) создают больше так называемого «шума», чем жёсткий диск. К сожалению, даже это не решает проблему виртуальных серверов, т.к. там генерировать энтропию практически нечему. Но тут на помощь приходит инструмент haveged. Основанный на алгоритме HAVEGE (а ранее – на его библиотеке), haveged позволяет генерировать случайные данные, руководствуясь изменениями во времени выполнения кода на процессоре.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
kotomyava
@kotomyava
Системный администратор
Что-то не так с конфигурацией, вероятнее всего.
Попробуйте запустить из консоли /usr/sbin/php-fpm7.2 --nodaemonize --fpm-config /etc/php/7.2/fpm/php-fpm.conf и посмотреть, на что он будет ругаться.
Ответ написан
polyanin
@polyanin Автор вопроса
Golang, PHP & Symfony developer
Как временное решение, добавил в
/lib/systemd/system/php7.2-fpm.service
строку
TimeoutSec=600
Стартует спустя минуту и 44 сек.
Может найдётся нормальное решение позже.
UPD Задача решилась с помощью техподдержки Netangels, установкой пакета haveged.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы