Долго запускается ubuntu 18.04 на SSD

[dikiyZ]

У меня в очередной раз начала тормозить загрузка в ssd. Исправил.
 Есть несколько простых правил для контроля:
1. systemd-analyze blame - не показывает реально кто тормозит загрузку. Это фейковый показометр.
2. смотреть виновных необходимо после начала загрузки системы, нажав на "escape".
3. Лично в моём случае виновен был один из модулей в автозагрузке, связанный с сетью.
две минуты он просто задерживал запуск, ожидая от dhcp сервера адрес, которого не получал.
Можно вводить заклинания в чёрном окошке, как старообрядцы:
 systemctl list-unit-files --state enabled   - даёт список автозагрузки
sudo systemctl disable здесь-имя-сервиса-из-списка   - убрать из автозапуска.
Либо в stacer посмотреть автозагрузку и ползунки поубирать на тех, которые висят при запуске, ожидая незнамо чего.

[jurganov]

Можно вводить заклинания в чёрном окошке, как старообрядцы:

а можно поковыряться в реестре )))

[zg_nico]

systemd-analyze ... Это фейковый показометр.

Пруфы будут, или Вас можно сразу штрафовать по п 2.3 Правил?

[dikiyZ]

 Напишите, что необходимо, скопирую. А Вы не знали, что  systemd-analyze blame  не показывает весь зоопарк, участвующий в автозапуске??
 У меня, например:
systemctl list-unit-files --state enabled

(Нажмите, чтобы показать/скрыть)

acpid.path                    enabled
cups.path                     enabled
resolvconf-pull-resolved.path enabled
accounts-daemon.service       enabled
acpid.service                 enabled
anacron.service               enabled
anydesk.service               enabled
apparmor.service              enabled
bluetooth.service             enabled
console-setup.service         enabled
cron.service                  enabled
cups.service                  enabled
dbus-org.bluez.service        enabled
dnsmasq.service               enabled
gpu-manager.service           enabled
ipsec.service                 enabled
isc-dhcp-server6.service      enabled
keyboard-setup.service        enabled
lm-sensors.service            enabled
miredo.service                enabled
networkd-dispatcher.service   enabled
networking.service            enabled
nmbd.service                  enabled
ondemand.service              enabled
openvpn.service               enabled
pppd-dns.service              enabled
resolvconf.service            enabled
strongswan.service            enabled
teamviewerd.service           enabled
ubuntu-fan.service            enabled
udisks2.service               enabled
ufw.service                   enabled
upower.service                enabled
acpid.socket                  enabled
cups.socket                   enabled
uuidd.socket                  enabled
anacron.timer                 enabled
fstrim.timer                  enabled

а теперь глядим выхлоп
systemd-analyze blame

(Нажмите, чтобы показать/скрыть)

5.683s nmbd.service
           994ms networkd-dispatcher.service
           962ms ufw.service
           662ms dev-sda2.device
           485ms NetworkManager.service
           482ms udisks2.service
           437ms teamviewerd.service
           431ms dnsmasq.service
           407ms accounts-daemon.service
           395ms gpu-manager.service
           346ms grub-common.service
           337ms upower.service
           327ms squid.service
           283ms networking.service
           273ms systemd-modules-load.service
           258ms systemd-udevd.service
           234ms dhcpcd.service
           185ms polipo.service
           183ms apparmor.service

Поэтому с Вашей стороны достаточно просто извиниться.

[ALiEN]

а теперь глядим выхлоп
systemd-analyze blame

прокрутить не пробовали? Это просто кусок полного списка.
У меня 61 строка. Причем показывает и мои "самописные" юниты. Почему у вас 19 - вопрос.

[dikiyZ]

...так я поубивал оттуда кучу всего. К примеру: wicd давно удалён, через purge, а в systemd-analyze blame - пожалуйста, показывал. Поэтому я и назвал эту приблуду фейковой.
 Посмотрел в истории parcellite, что я удалял ввиду того, что в системе автозагрузки давно таких пакетов нет, как и в системе: minidlna.service, dns2tcp.service, shadowsocks.service, rtkit-daemon.service, systemd-rfkill.service, preload.service, teamviewerd.service и т.д.
 Как оказалось, там мусора куча. locate не находит в системе такого. Удаление всего этого "добра" никак не повлияло на работоспособность. В любом случае, такого количества сервисов в автозапуске быть не должно.
 В процессе было выяснено, что многие сервисы команда  не отображала. Например, у меня задерживала запуск на две минуты приблуда sys-subsystem-net-devices-multi-user.device. Это стало видно визуально после нажатия escape во время запуска.
 При этом, после загрузки systemd-analyze blame вообще не показывала это дело и всё выглядело прям идеально по времени.
 

[ALiEN]

dikiyZ,

Код: [Выделить]

systemd-analyze plot > ~/systemd-load.svg
картинку на хостинг - показывайте.

[zg_nico]

Поэтому с Вашей стороны достаточно просто извиниться.

А, пардон, за что? Смотрим на выводы:

Код: [Выделить]

systemd-analyze blame | wc -l
80
systemctl list-unit-files --state enabled | wc -l
81
#и, собственно, откуда разница в одну строчку:
systemd-analyze blame | head
           689ms keyboard-setup.service
           465ms dev-sda6.device
           446ms udisks2.service
           445ms postfix@-.service
           410ms systemd-logind.service
           365ms mnt-NTFSpart.mount
           294ms systemd-fsck@dev-disk-by\x2duuid-81AE\x2d22EB.service
           276ms gpu-manager.service
           271ms ModemManager.service
           264ms grub-common.service
systemctl list-unit-files --state enabled | head
UNIT FILE                                  STATE 
acpid.path                                 enabled
apport-autoreport.path                     enabled
cups.path                                  enabled
accounts-daemon.service                    enabled
anacron.service                            enabled
apparmor.service                           enabled
autovt@.service                            enabled
avahi-daemon.service                       enabled
binfmt-support.service                     enabledИными словами, второй вывод тупо дается с заголовком (что, кстати, решается ключом --no-legend). А так все совпадает до единой записи. Если у Вас не совпадает сразу после запуска, либо вывод числа запущенных больше, чем в хронологии запуска, - думайте, и вспоминайте чего в своей системе "настругали".
Но проще конечно же на утилиту ругаться. Она же ответить не может, да?!

[Karl500]

(Нажмите, чтобы показать/скрыть)

На самом деле, если бы разница была из-за заголовка, то количество строк должно бы быть больше во втором случае...

[zg_nico]

(Нажмите, чтобы показать/скрыть)

Karl500, спасибо. Исправил сообщение. Выводы местами перепутал в первый раз.

[ALiEN]

хм

Код: [Выделить]

$: systemd-analyze blame | wc -l
59
$: systemctl list-unit-files --state enabled | wc -l
28


[zg_nico]

(Нажмите, чтобы показать/скрыть)

ALiEN175, ну так правильно!
Karl500 запутал меня окончательно Вывод я верно привел в первый раз. Исправил сообщение снова к стоковому состоянию. Сейчас проверяю:

Код: [Выделить]

zg_nico@Thunderobot-G150T-S50:~$ systemd-analyze blame | wc -l
79
zg_nico@Thunderobot-G150T-S50:~$ systemctl list-unit-files --state enabled | wc -l
80
zg_nico@Thunderobot-G150T-S50:~$ systemctl list-unit-files --no-legend --state enabled | wc -l
77Создали проблему на пустом месте. Сейчас будем её мусолить до посинения 

[ALiEN]

стоп-стоп!
почему у меня в списке enabled в два раза меньше строк чем в blame?

Это systemd как-то хитро работает, либо я не понял? 

[AnrDaemon]

Первое. Некоторые юниты на лету генерят "деток" по @шаблонам .

[dikiyZ]

zg_nico, я извиняюсь за свой резкий тон, мне не стоило вести себя так.

e@e:~$ systemd-analyze blame | wc -l
64
e@e:~$ systemctl list-unit-files --state enabled | wc -l
40
e@e:~$ systemctl list-unit-files --no-legend --state enabled | wc -l
37
e@e:~$
Каждый может выбрать себе циферку показометра по вкусу... . Это я уже после многочисленных экспериментов скопировал, до этого было около 20.

Что-то удалял я и сервисы, и сами приложения, а в прилагаемом способе вывода истории загрузки в файл, systemd-analyze plot > ~/systemd-load.svg, снова появились wicd pdnsd и куча прочих. Нет их в системе, не обнаруживаются ни поиском, ни в виде locate wicd*. Устал я от этой ерунды... грохну и заново поставлю 20.04 в мае.