Эй, линуксоид! 👋
Знакома ситуация: отправил сервер в reboot, и можно идти варить кофе, потому что он поднимается мучительно долго? 😤 Часто виноват один-единственный «зависший» сервис, который тянет время всей системы.
В systemd есть встроенный инструмент-детектив, который покажет, кто именно крадет твои секунды.
📌 1. Оцениваем общий масштаб бедствия
Сначала посмотрим, сколько времени ушло на загрузку в целом (ядро + userspace).
$ systemd-analyze
Startup finished in 253ms (kernel) + 933ms (initrd) + 6.873s (userspace) = 8.060s
Это дает общее понимание: если userspace занимает слишком много времени, значит, проблема в службах.
📌 2. Ищем виновника (команда blame)
Эта команда выводит список всех запущенных юнитов, отсортированных по времени инициализации — от самых медленных к самым быстрым.
$ systemd-analyze blame
3.811s NetworkManager-wait-online.service
806ms tuned.service
680ms postfix.service
490ms lvm2-monitor.service
...
В данном примере видно, что NetworkManager-wait-online.service задерживает запуск почти на 4 секунды.
📌 3. Анализируем критический путь
Иногда сервис запускается долго, но не тормозит остальных. Чтобы увидеть дерево зависимостей и понять, какой процесс реально блокирует финиш загрузки, используйте:
$ systemd-analyze critical-chain
graphical.target @9.663s
└─multi-user.target @9.661s
└─snapd.seeded.service @9.062s +62ms
└─basic.target @6.336s
└─sockets.target @6.334s
└─snapd.socket @6.316s +16ms
└─sysinit.target @6.281s
└─cloud-init.service @5.361s +905ms
└─systemd-networkd-wait-online.service @3.498s +1.860s
Здесь видно, что systemd-networkd-wait-online.service является узким местом в цепочке,.
💡 Совет:
Если вы нашли «тормоза», которые вам не нужны (например, postfix на рабочей станции или ожидание сети там, где это не критично), их можно отключить (systemctl disable) или оптимизировать.
#Linux #Systemd #DevOps #SysAdmin #Performance