systemd-analyze to narzędzie diagnostyczne systemd, które pokazuje, ile trwał start systemu i które usługi go spowalniają. Uruchomione bez argumentów wypisuje sumaryczny czas rozruchu z podziałem na jądro (kernel), initrd i przestrzeń użytkownika (userspace). Przydaje się, gdy Twój serwer albo laptop wstaje wolniej niż zwykle i chcesz wiedzieć, kto jest winny, zamiast strzelać w ciemno. Poza analizą bootu potrafi też sprawdzać poprawność plików .service i oceniać ich bezpieczeństwo.
Składnia i najważniejsze opcje
Podstawowa forma to systemd-analyze [polecenie] [argumenty]. Najczęściej używane podpolecenia:
time— domyślne (działa też bez podania), pokazuje łączny czas rozruchu z rozbiciem na kernel/initrd/userspaceblame— lista jednostek posortowana wg czasu, jaki zajęła ich inicjalizacja (najwolniejsze na górze)critical-chain— drzewo ścieżki krytycznej rozruchu; czas po znaku@to moment aktywacji, po+czas startu jednostkiplot— generuje wykres SVG z osią czasu startujących usług (przekierowujesz go do pliku)verify— sprawdza pliki jednostek pod kątem błędów i potencjalnych problemówsecurity— ocenia ustawienia sandboxingu usług i wylicza „poziom ekspozycji” w skali 0.0–10.0dump— zrzuca pełny stan wewnętrzny menedżera (dużo tekstu, do głębszego debugowania)
Przykłady użycia
systemd-analyze— szybki podgląd: ile sekund zajął cały rozruch i jak rozłożył się na etapy.systemd-analyze blame— znajdziesz usługę, która pożera 20 sekund startu (np. jakiś powolnyNetworkManager-wait-online).systemd-analyze critical-chain— pokazuje, co realnie blokowało rozruch, bo powolna usługa uruchamiana równolegle nie zawsze wydłuża boot.systemd-analyze plot > boot.svg— zapisuje wizualną oś czasu do pliku, który otworzysz w przeglądarce.systemd-analyze security nginx.service— audyt bezpieczeństwa konkretnej usługi z listą ustawień do zaostrzenia.
Częste błędy i pułapki
Najczęstsza pomyłka to mylenie blame z critical-chain. blame pokazuje najwolniejsze jednostki, ale wiele z nich startuje równolegle i wcale nie opóźnia bootu — realną winę widać dopiero w critical-chain. Druga pułapka: czasy z systemd-analyze time nie obejmują pracy bootloadera ani BIOS/UEFI, więc jeśli sprzęt „myśli” 30 sekund przed GRUB-em, tu tego nie zobaczysz. Pamiętaj też, że dane dotyczą ostatniego rozruchu — po zmianach w usługach trzeba zrestartować system, żeby pomiary miały sens. I nie panikuj widząc security z oceną 9.0 dla przypadkowej usługi — wysoki wynik to sugestia, a nie awaria.
Powiązane komendy: systemctl, journalctl, systemd-cgtop, systemd-bootchart.