Почему не стартует php7.2-fpm после ребута?
Александр Владимирович, давайте поясню, раз не только у вас такая штука, как наблюдаю в комментариях.Более полное описание ситуации: проблема есть только при старте системы. Если перезапустить сервис на работающей машине все достаточно быстро поднимается. Пример как отлавливать баги в случае старта сервисов из под 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 позволяет генерировать случайные данные, руководствуясь изменениями во времени выполнения кода на процессоре.
Александр Владимирович, давайте поясню, раз не только у вас такая штука, как наблюдаю в комментариях.Более полное описание ситуации: проблема есть только при старте системы. Если перезапустить сервис на работающей машине все достаточно быстро поднимается. Пример как отлавливать баги в случае старта сервисов из под 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 позволяет генерировать случайные данные, руководствуясь изменениями во времени выполнения кода на процессоре.