Иногда сервер после reboot поднимается подозрительно долго. Вроде железо нормальное, диск живой, сервисов не так много, но до нормального состояния система доходит через минуту, две или даже дольше.
В systemd для такого разбора есть удобная утилита:
systemd-analyze
Она покажет общее время загрузки:
Startup finished in 5.2s (kernel) + 28.4s (userspace) = 33.6s
Здесь видно, сколько заняло ядро и сколько - userspace, то есть запуск systemd-сервисов.
▪️ Чтобы понять, какие иниты запускались дольше всего:
systemd-analyze blame
Пример вывода:
12.834s docker.service
8.421s NetworkManager-wait-online.service
6.102s postgresql.service
3.451s nginx.service
Это хороший первый ориентир, но есть важный нюанс.
blame показывает длительность запуска юнитов, но не всегда показывает реального виновника. Сервисы могут запускаться параллельно, и длинный сервис не обязательно блокировал всю загрузку. ▪️ Для понимания цепочки зависимостей лучше использовать:
systemd-analyze critical-chain
Эта команда показывает критический путь загрузки - что действительно задерживало достижение нужного target.
▪️ Можно посмотреть цепочку для конкретного сервиса:
systemd-analyze critical-chain docker.service
▪️ Частые причины долгой загрузки:
ожидание сети
зависший mount из /etc/fstab
медленный DNS
NFS/SMB mount без `nofail`
долгий старт базы данных
Docker/container runtime
cloud-init
некорректные зависимости в юнитах
таймауты несуществующих устройств
▪️ Отдельно стоит проверить failed-юниты:
systemctl --failed
▪️ Логи текущей загрузки:
journalctl -b
Если проблема была на предыдущем boot:
journalctl -b -1
▪️ Еще полезная команда - построить SVG-график загрузки:
systemd-analyze plot > boot.svg
Файл
boot.svg можно открыть в браузере и визуально посмотреть, какие сервисы когда стартовали и сколько длились.▪️ Для поиска ошибок в unit-файлах:
systemd-analyze verify /etc/systemd/system/myapp.service
Это помогает поймать неправильные директивы, опечатки и странности в конфигурации.
#linux #systemd
🧑💻 NetworkAdmin