LINUX.ORG.RU

Долгая загрузка Plasma 5.20.2 после старта SDDM

 , , ,


0

1

Всем привет! Дистрибутив, на котором это происходит – KDE neon соотв. версии (последняя стабильная). Корень на SSD, домашней директории лет семь и сейчас она находится на относительно быстром 2.5" HDD. В $(journalctl -b) ничего особо интересного (похоже, для профайлинга следует скомпилировать плазму для отладки, чего очень не хочется делать).

Подозрение падает на загрузку startplasma_x11 файлов из домашней директории – в связи с этим я пытался чистить .config, .cache, точечно директории kde и plasma в .local, а также отключать службы (очевидно, прироста особого последнее не дает, но я все равно попробовал после того, как заново настроил профиль пользователя). Свежесозданные пользователи грузятся мгновенно.

Подскажите, что я могу попробовать в дальнейшем, чтобы привести время загрузки существующего профиля к минимуму? Благодарю.

★★

Ответ на: комментарий от chaos_dremel

Возможно, это ни о чем не говорит, но:

 ~  time . .bashrc

real    0m0,354s
user    0m0,243s
sys     0m0,063s
Внутри powerline-shell, автодополнение для pip, немного алиасов и переменных окружения — 61 строка. В .profile же просто подгрузка .bashrc

mazdai ★★ ()
Ответ на: комментарий от mazdai

Сильно сомневаюсь, что я один сталкивался с этим и, скорее всего, есть способ относительно малой кровью отследить, что именно и почему грузится из $HOME во время запуска плазмы. Поэтому бампаю тему.

mazdai ★★ ()
Ответ на: комментарий от andytux

Да еж… Это же самое первое, что предлагается в выдаче нескольких поисковиков при запросе на эту тему. Пожалуйста:

 ~  systemd-analyze blame
### В предыдущий запуск комп был перезагружен силой, поэтому на проверку ФС ушло некоторое время
1min 16.117s fstrim.service                                                   
     49.971s systemd-fsck@dev-disk-by\x2duuid-25eb2d25\x2d402f\x2d42e4\x2dbb0e>
      1.237s fwupd-refresh.service                                            
      1.190s man-db.service                                                   
      1.048s nfs-server.service
### Ниже остальные службы, время загрузки здесь чуть выше среднего в моем обычном и новом профилях, нет заметных различий между ними                                              
       886ms udisks2.service                                                  
       811ms smartmontools.service                                            
       617ms user@1000.service                                                
       558ms docker.service                                                   
       422ms vboxdrv.service                                                  
       323ms apt-daily-upgrade.service                                        
       303ms systemd-logind.service                                           
       303ms networkd-dispatcher.service                                      
       300ms apt-daily.service                                                
       288ms accounts-daemon.service                                          
       260ms avahi-daemon.service                                             
       257ms NetworkManager.service                                           
       222ms gpu-manager.service                                              
       221ms polkit.service                                                   
       213ms dev-nvme0n1p1.device                                             
       210ms grub-initrd-fallback.service                                     
       207ms grub-common.service                                              
       197ms thermald.service

Тормоза в загрузке начинаются строго после запуска SDDM и X/сессии Plasma. Могу вывод journalctl приложить, но сам я там ничего особо интересного не нашел на эту тему.

mazdai ★★ ()
Ответ на: комментарий от mazdai

Вот вывод blame сразу после создания пользователя и с автоматическим логином после перезагрузки. nfs-server появился недавно, скорее всего после того, как я повозился с vagrant и sshfs – не сильно отразилось на времени загрузки и не сильно повлияет, если отключить этот юнит через systemctl. Вот вывод journalctl -b. @andytux

mazdai ★★ ()
Последнее исправление: mazdai (всего исправлений: 1)
Ответ на: комментарий от zzz4

установлен и работает с момента установки системы. я говорю вам, что загрузка собственно сессии Plasma со старым профилем занимает гораздо больше времени, чем с новым. Меня устраивает время загрузки нового профиля, но что именно грузится в старом столь долго, мне неизвестно и как это узнать (логировать доступ к диску и файлам по уму, чтобы не потеряться как в выводе strace например), тоже; на новый профиль крайне не хотелось бы переходить и долго переносить всю конфигурацию

mazdai ★★ ()
Последнее исправление: mazdai (всего исправлений: 3)
Ответ на: комментарий от RedEyedMan666

Они и стоят на SSD, но во время загрузки что-то интенсивно грузят с ЖД. Могу показать .bashrc, но сомневаюсь, что 2-3 секунды, потраченные на инициализацию virtualenvwrapper и powerline-shell, будут заметны на фоне 30-40 секунд загрузки после старта SDDM

mazdai ★★ ()
Ответ на: комментарий от mazdai

как ты «чистил» .config? обычно делают копию и удаляют оригинал.

посмотри выхлоп systemd-analyze --user blame

попробуй запустить iotop и посмотреть что грузит диск. можешь это сделать (ВНЕЗАПНО!) в другом tty.

anonymous ()
Ответ на: комментарий от mazdai

Меня устраивает время загрузки нового профиля, но что именно грузится в старом столь долго, мне неизвестно и как это узнать

если есть свободное время, то можете переносить по пару файликов со старого профиля в новый, и методом тыка определить в чём трабла, или вон как анонимус предложил глянуть iotop, и да baloo выключен?

zzz4 ()
Ответ на: комментарий от anonymous
 ~  systemd-analyze --user blame
310ms pulseaudio.service 
  3ms gvfs-daemon.service
  2ms dbus.socket

Было бы круто нечто вроде iotop запустить в качестве сервиса до достижения multi-user.target или graphical.target. После загрузки системы особо ничего не отъедается и перезапуск SDDM происходит относительно быстро. Попробую сейчас сделать замеры. Действительно, sddm stop и sddm [re]start дают очень быструю загрузку старого профиля (подкачки нет, много оперативы), ничего жрущего трафик с дисками не увидел. Нужно каким-то образом посмотреть это в первую загрузку.

mazdai ★★ ()
Последнее исправление: mazdai (всего исправлений: 1)
Ответ на: комментарий от zzz4

baloo отключен, файликов дохреналлион, поэтому я стараюсь найти любой другой способ сперва. из .config я удалял лишь то, что относилось к kde и plasma, точно директории не помню, но после этого мне пришлось пересоздать весь профиль – и это не уменьшило времени загрузки в тот раз.

mazdai ★★ ()
Ответ на: комментарий от mazdai

нуу я могу сказать одно, нужно удалять всё связанное с qt/k*, и делать полный снос ~/.cache, и да есть ли возможность запустить кде без sddm? sddm служба вроде как не выводит stdout/stderr запущенной оболочки, хотя оно вроде как должно писать в journalctl

zzz4 ()
Ответ на: комментарий от mazdai

Проверь свой virtualenv. Может ты в него что-то положил и это подгружается с HDD. Но всю эту Байден[ь] лучше удалить из автозагрузки, чтобы хотя бы найти виновника методом исключения.

RedEyedMan666 ()
Последнее исправление: RedEyedMan666 (всего исправлений: 1)
Ответ на: комментарий от zzz4

Вроде как я сносил уже все, что было связано с qt и kde, включая настройки Qt4 и Qt5 и директорию .cache. Да, если сейчас startplasma_x11 или как там эта фигня зовется запускается еще из шелла, а не через dbus сигналы исключительно, то я смогу запустить чистую сессию и смотреть логи в tty. Пока не пробовал, по идее все то же самое должно быть в выводе journalctl. Сперва попробую предложения других участников, в любом случае благодарю!

mazdai ★★ ()

Если это кому-нибудь поможет: я сделал новый профиль и понемногу переносил в него конфигурацию. Это не повлияло на скорость загрузки, а повлияло копирование директорий .fonts, .themes, .icons. Наблюдения продолжаются

mazdai ★★ ()