При длительной загрузке сервера после перезагрузки не требуется вручную анализировать каждый сервис.
systemd сохраняет информацию о процессе запуска и позволяет определить компоненты, которые влияют на время старта системы.Первый этап анализа — общее время загрузки:
systemd-analyze
Пример вывода:
Startup finished in 4.2s (kernel) + 35.8s (userspace) = 40.0s
kernel показывает время загрузки ядра, а userspace — время запуска systemd, сервисов и пользовательского пространства. На некоторых системах дополнительно отображаются этапы firmware, loader и initrd.Если основная задержка находится в
userspace, дальнейший анализ выполняется через systemd юниты и их зависимости. Для поиска юнитов с длительной активацией используется:systemd-analyze blame
Пример:
45.231s docker.service
32.814s NetworkManager-wait-online.service
18.502s nginx.service
Команда показывает время активации юнитов, но не является точным показателем их влияния на общую загрузку.
systemd запускает множество компонентов параллельно, поэтому результат требует дополнительной проверки.Для анализа реальной цепочки зависимостей используется:
systemd-analyze critical-chain
Пример:
multi-user.target @40.012s
└─docker.service @35.421s +4.580s
└─network-online.target @35.400s
└─NetworkManager-wait-online.service @2.561s +32.814s
Символ
@ показывает момент активации юнита, а + — продолжительность его запуска. Такой вывод позволяет определить, какой компонент находится в критической цепочке и задерживает достижение target.Один из частых случаев —
NetworkManager-wait-online.service, который ожидает готовности сети перед продолжением загрузки. На серверах без необходимости ждать полного поднятия сети он может увеличивать время старта, однако отключение этого сервиса требует проверки зависимостей от network-online.target.Для визуального анализа процесса загрузки:
systemd-analyze plot > boot.svg
Файл
boot.svg содержит временную диаграмму запуска юнитов и позволяет увидеть параллельные процессы, последовательные зависимости и точки задержек.Для проверки конкретного сервиса:
systemctl status docker.service
Время запуска основного процесса можно получить командой:
systemctl show docker.service -p ExecMainStartTimestamp
А причины ошибок и тайм-аутов анализируются через журнал
systemd:journalctl -b -u docker.service
Для предыдущей загрузки:
journalctl -b -1 -u docker.service
Отключать сервисы только на основании
systemd-analyze blame некорректно. Перед изменением конфигурации необходимо проверить назначение юнита, наличие зависимостей и сообщения в журнале.🔥
systemd-analyze позволяет определить проблемный этап загрузки, найти критические зависимости и локализовать причину задержки без ручного просмотра большого количества конфигурационных файлов.🚪 Linux Ready | #практика