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

Можно посмотреть файлы .profile и .bashrc на предмет сторонних включений. Можно сравнить их с аналогичными файлами у новых пользователей

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

 ~  time . .bashrc

real    0m0,354s
user    0m0,243s
sys     0m0,063s

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

Сравни «systemd-analyze blame» для разных пользователей.

А KDE свои процессы не в обход systemd грузит разве?

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

 ~  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 приложить, но сам я там ничего особо интересного не нашел на эту тему.

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

Ну вот, теперь и кедоплазму ставь на SSD (шутка).

может быть нехватка энтропии? попробуй поставить&включить haveged

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

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

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

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

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

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

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

 ~  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 дают очень быструю загрузку старого профиля (подкачки нет, много оперативы), ничего жрущего трафик с дисками не увидел. Нужно каким-то образом посмотреть это в первую загрузку.

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

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

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

тогда смотри логи sddm journalctl -eu sddm и иксов после первой загрузки и после перезапуска. потом сравни их.

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

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