[ @console @systemd ]
Это сразу не нужно, но позже будет очень полезно.
Можно проверить, быстро ли загружается система:
systemd-analyze
Пример ответа:
graphical.target reached after 18.984s in userspace
На всякий случай — в одной секунде тысяча милисекунд.
Эти цифры надо воспринимать очень спокойно, потому что даже если система будет загружаться за три секунды, поднятие GUI и всех сопуствующих процессов может занимать и полторы минуты. Или больше.
Узнать, что именно загружается
при включении ноута, и если что-то не очень нужно, то — убить или подавить.
Простым списком
systemd-analyze blame
Пример ответа:
8.362s NetworkManager-wait-online.service
4.061s apt-daily.service
2.198s ifupdown-pre.service
886ms nvidia-persistenced.service
764ms udisks2.service
743ms smartmontools.service
586ms lightdm.service
583ms plymouth-quit-wait.service
Наглядной цепочкой
systemd-analyze critical-chain graphical.target
Пример ответа:
graphical.target @11.665s
└─multi-user.target @11.665s
└─exim4.service @11.478s +187ms
└─network-online.target @11.476s
└─NetworkManager-wait-online.service @3.112s +8.362s
└─NetworkManager.service @3.005s +105ms
В графике
systemd-analyze plot > fileAnalyze.svg && gimp fileAnalyze.svg
Увеличить и на, смотри последовательно, что после чего загружаеццо…
Отключить что-то
Очень осторожно! В погоне за секундой можно запороть систему.
«systemd-timesyncd.service» точно не надо отключать.
В принципе безопасно отключить штатный «NetworkManager-wait-online.service» (ещё может называться «systemd-networkd-wait-online.service»), у меня это высвободит восемь секунд. Этот сервис «ждёт», когда ноут подключится к сети, и только ПОСЛЕ этого запускает остальные сервисы. Это логично, ведь зачем их запускать, если им будет нужен доступ в сеть?! Но на это можно забить.
sudo systemctl status systemd-networkd-wait-online.service
sudo systemctl stop systemd-networkd-wait-online.service
sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl mask systemd-networkd-wait-online.service
Последняя команда делает сервису symlink в [[/dev/null.]> Это нужно из-за того, что если стартап какого-то сервиса погашен, но его «попросит» другой сервис/процесс, то сервис всё равно будет загружен.
Ещё можно по аналогичной схеме «прибить» сервис bluetooth.service — если он, конечно же, не нужен и не будет нужен позже. Возможно, будет разумнее отключить его в
Параметры системы
> Запуск и завершение
> Управление службами
sudo systemctl status bluetooth.service
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service
sudo systemctl mask bluetooth.service
Забить snap
Это будет посложнее. Вместо «sudo systemctl disable snapd.service» надо проверить, есть ли у него родственники: «systemd-analyze blame | grep snap» (если проверяем snap). Если таки да, то лучше сервис дополнительно ещё и замаскировать:
sudo systemctl stop snapd.service
sudo systemctl disable snapd.service
sudo systemctl mask snapd.service