Plasma takes almost a minute from login to usable desktop

[Barbosabyte]

Hello.

I'm having an issue at login.

Plasma (5.10.2) takes around 57 seconds from login (sddm) to usable (with icons and panel).
I can't seem to find the culprit.
Where can I check what's taking so much time?
What info do you need to help?

Thank you in advance.

[acheron]

First try 5.10.3 which I just copied to backports. I've seen at least one person say that version fixed a slow plasma startup issue.

[Barbosabyte]

Tried it.
It actually increased startup time to 1min and 10 secs.

[GreyGeek]

Tried it.
It actually increased startup time to 1min and 10 secs.

Plasma 5.10.3 decreased my sddm login to active desktop time from about 45 seconds to 20 seconds. My desktop makes my secondary GPU, an NVidia GT650M, behave as the primary GPU.

Perhaps checking your GPU settings, what services you have active, etc...

[Barbosabyte]

Looking at journalctl the biggest gaps in time are

jun 29 21:37:23 andre-All-Series systemd[1203]: Started D-Bus User Message Bus.
jun 29 21:37:31 andre-All-Series dbus-daemon[1241]: Activating service name='org.kde.kglobalaccel'

and

jun 29 21:37:45 andre-All-Series dbus[819]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
jun 29 21:37:52 andre-All-Series dbus-daemon[1241]: Activating service name='org.freedesktop.Notifications'
jun 29 21:38:10 andre-All-Series systemd[1]: Started Daemon for generating UUIDs.

[oshunluvr]

Try this and post the top offenders:

sudo systemd-analyze blame

[vinnywright]

vinny@vinny-Bonobo-Extreme:~$ systemd-analyze blame 
       6.039s NetworkManager-wait-online.service
       4.331s dev-sda1.device
       3.217s mnt-sdb1.mount
      [COLOR=#ff0000] 2.903s ModemManager.service[/COLOR]
       2.614s accounts-daemon.service
       2.532s NetworkManager.service
       2.454s gpu-manager.service
       [COLOR=#ff0000]1.869s minidlna.service[/COLOR]
       1.852s thermald.service
       1.797s polkit.service
       1.597s grub-common.service
       [COLOR=#ff0000]1.409s avahi-daemon.service[/COLOR]
       1.402s keyboard-setup.service
       1.116s bluetooth.service
        909ms irqbalance.service
        870ms networking.service
        843ms rsyslog.service
        651ms apparmor.service
        563ms systemd-udevd.service
        540ms systemd-modules-load.service
        540ms systemd-resolved.service
        504ms dev-disk-by\x2duuid-98d20e91\x2d1908\x2d48a9\x2db713\x2dc4aa0fd8b055.swap
        402ms systemd-fsck@dev-disk-by\x2duuid-ff5d66d4\x2d35b6\x2d4c9c\x2da64e\x2d8dfbe2aa1e31.service
        400ms systemd-rfkill.service
        353ms kmod-static-nodes.service
        352ms dev-mqueue.mount
        347ms home.mount
        345ms resolvconf.service
        332ms colord.service
        331ms systemd-tmpfiles-setup-dev.service
        329ms systemd-backlight@backlight:acpi_video0.service
        309ms apport.service
        308ms sys-kernel-debug.mount
        307ms dev-hugepages.mount
        301ms systemd-logind.service
        284ms systemd-user-sessions.service                                                                                         
        238ms packagekit.service                                                                                                    
        218ms systemd-journald.service                                                                                              
        218ms systemd-tmpfiles-setup.service                                                                                        
        216ms systemd-sysctl.service                                                                                                
        185ms upower.service                                                                                                        
        170ms systemd-timesyncd.service                                                                                             
        166ms systemd-remount-fs.service
        159ms wpa_supplicant.service
        132ms user@119.service
        131ms ufw.service
        121ms sddm.service
        115ms setvtrgb.service
        106ms plymouth-read-write.service
        104ms systemd-udev-trigger.service
         91ms console-setup.service
         78ms udisks2.service
         70ms nvidia-persistenced.service
         51ms rtkit-daemon.service
         46ms systemd-update-utmp.service
         36ms pppd-dns.service
         32ms systemd-random-seed.service
         23ms systemd-journal-flush.service
         22ms plymouth-quit.service
         16ms plymouth-start.service
         11ms user@1000.service
          6ms ureadahead-stop.service
          5ms alsa-restore.service
          5ms systemd-update-utmp-runlevel.service
          4ms snapd.autoimport.service
          1ms sys-fs-fuse-connections.mount
          1ms snapd.socket

the ones in red could be disabled for sure ,,,,,but I get to desktop in about 20sec ,,so it dose not bother me.

you can do it in a GUI if you install "kde-config-systemd" ,,,it will add a systemd section to system settings where you can "mask"it/them.

VINNY

OOPS posted over you @oshunluvr

[Barbosabyte]

Here are the ones that take more than 3 seconds:

        17.910s dev-sda2.device
        15.656s keyboard-setup.service
        15.578s proc-fs-nfsd.mount
        13.917s systemd-udevd.service
         4.853s run-rpc_pipefs.mount
         4.365s NetworkManager.service
         4.353s gpu-manager.service
         4.353s accounts-daemon.service
         4.118s resolvconf.service
         3.800s ModemManager.service

The first one is probably my hdd showing it's age, but the next 3, why are they taking so long?

[kubicle]

"systemd-analyze blame" isn't all that helpful when debugging user-session startup time, because these system services have generally already started when the login screen (sddm) comes up, so you may get some useful debug info if you are trying to analyze the startup "from boot to sddm" (but not "from sddm to user desktop").

Also, even if you are measuring "boot to sddm", you should not put too much weight on the times reported. The times reported are the times spend initializing a particular service, but do not necessarily tell how much that delays the boot as sometimes services are just waiting for other services to come up...and commonly many services start simultaneously with others. You will usually get better/more detailed info by running something like "systemd-analyze plot > boot.svg" and viewing the "boot.svg" graphic afterwards (but like I said, only if you are examining "from boot to sddm".

[Barbosabyte]

From boot to sddm the times are reasonable (on par with other distros), the real problem is sddm to desktop. I tried creating a new user to check if it was something with my session, but it behaves the same.

[oshunluvr]

It's interesting how different all of ours are - not just time but sequence of events. My system boots in a flash but it's new and high-end. The longest wait for me is 5.4 seconds for the network, second longest 494ms to mount my backup drive, everything else is less than 284ms.

I'd almost 18 seconds to bring a drive up and the other top 3 are an issue. You said other distros get you to login in faster, what about booting to one of them, running blame again and comparing?

[oshunluvr]

Kubicle brings up a good point tho, because many if not most of these services start in parallel. The plot graphic gives a better picture of what's causing the delay. My plot shows about 10 services waiting for the network to start. It could very well be how your user is set up. I would create a second user and log into a "clean" desktop to see if the delay varies noticeably.

[Barbosabyte]

I tried a new user. It's the same.
I tried a different DE (lxqt) and it came down to 20 sec.
I starting to think it is something relative to kwin.

[oshunluvr]

You didn't say, but it could be video driver related as well. I had a lot of trouble with the default nvidia driver at my initial install.

[Barbosabyte]

I have a knabini apu, so I'm using mesa 17.1.2.
I tried a KDE/openbox session to check if it was a kwin problem, but I still have the long wait (On the other hand ram usage dropped from 1gb to around 500mb), so it probably isn't a kwin issue.