Plasma Desktop takes very long to load

Hello Manjaro Community!

On my main PC plasma-desktop takes a very long time to load (1-3 Minutes, if not more on an SSD). This is not always the case (most of the time it starts just fine within a few seconds) but I failed to find a pattern when this happens.

After I login the following loading page already takes a unusual long time. Eventually it'll fade out and my desktop background image will fade in. But there is no taskbar and no widget. I can however start programs with yakuake or the plasma search which will show up immediately. After a few minutes everything (including programs in autostart (if there are any)) will show up. I can't see any unusual CPU usage.

What I've already done:

  • Checked my printers in /etc/cups/printers.conf
  • Removed ~/.kde4
  • Removed some programs from systemd: ckb-next, redshift, kvantum (list probably incomplete)

Hope you can help me,
Konachan

System:    Kernel: 4.19.66-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.1.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.19-x86_64 root=UUID=e1f2022e-034b-4275-8c92-d1da2bfba4eb rw quiet 
           resume=UUID=350327f8-ffde-4c27-b025-525c08dc2794 
           Desktop: KDE Plasma 5.16.4 tk: Qt 5.13.0 wm: kwin_x11 dm: SDDM Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASUSTeK model: P9X79 PRO v: Rev 1.xx serial: <filter> UEFI: American Megatrends v: 4607 
           date: 12/02/2013 
CPU:       Topology: Quad Core model: Intel Core i7-3820 bits: 64 type: MT MCP arch: Sandy Bridge family: 6 model-id: 2D (45) 
           stepping: 7 microcode: 718 L2 cache: 10.0 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 57658 
           Speed: 1201 MHz min/max: 1200/3800 MHz Core speeds (MHz): 1: 1201 2: 1201 3: 1200 4: 1201 5: 1201 6: 1201 7: 1201 
           8: 1201 
           Vulnerabilities: Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling 
Graphics:  Device-1: NVIDIA GP104 [GeForce GTX 1080] vendor: ZOTAC driver: nvidia v: 430.40 bus ID: 01:00.0 chip ID: 10de:1b80 
           Display: x11 server: X.Org 1.20.5 driver: nvidia compositor: kwin_x11 resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce GTX 1080/PCIe/SSE2 v: 4.6.0 NVIDIA 430.40 direct render: Yes 
Audio:     Device-1: Intel C600/X79 series High Definition Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 chip ID: 8086:1d20 
           Device-2: NVIDIA GP104 High Definition Audio vendor: ZOTAC driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           chip ID: 10de:10f0 
           Sound Server: ALSA v: k4.19.66-1-MANJARO 
Network:   Device-1: Intel 82579V Gigabit Network vendor: ASUSTeK P8P67 Deluxe driver: e1000e v: 3.2.6-k port: f040 
           bus ID: 00:19.0 chip ID: 8086:1503 
           IF: eno1 state: up speed: 100 Mbps duplex: half mac: <filter> 
Drives:    Local Storage: total: 4.91 TiB used: 289.89 GiB (5.8%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 840 PRO Series size: 476.94 GiB block size: physical: 512 B 
           logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 6B0Q scheme: MBR 
           ID-2: /dev/sdb vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 2B6Q scheme: MBR 
           ID-3: /dev/sdc vendor: Western Digital model: WD40EZRX-00SPEB0 size: 3.64 TiB block size: physical: 4096 B 
           logical: 512 B speed: 3.0 Gb/s rotation: 5400 rpm serial: <filter> rev: 0A80 scheme: GPT 
           ID-4: /dev/sdd vendor: Crucial model: M4-CT128M4SSD2 size: 119.24 GiB block size: physical: 512 B logical: 512 B 
           speed: 3.0 Gb/s serial: <filter> rev: 070H scheme: GPT 
           ID-5: /dev/sde vendor: SanDisk model: SD6SB1M-256G-1006 size: 238.47 GiB block size: physical: 512 B logical: 512 B 
           speed: 3.0 Gb/s serial: <filter> rev: 706 scheme: MBR 
Partition: ID-1: / raw size: 101.78 GiB size: 99.68 GiB (97.94%) used: 49.96 GiB (50.1%) fs: ext4 dev: /dev/sdd2 
           ID-2: swap-1 size: 17.17 GiB used: 1.2 MiB (0.0%) fs: swap swappiness: 60 (default) cache pressure: 100 (default) 
           dev: /dev/sdd3 
Sensors:   System Temperatures: cpu: 32.0 C mobo: N/A gpu: nvidia temp: 48 C 
           Fan Speeds (RPM): cpu: 0 gpu: nvidia fan: 0% 
Info:      Processes: 262 Uptime: 28m Memory: 15.61 GiB used: 3.17 GiB (20.3%) Init: systemd v: 242 Compilers: gcc: 9.1.0 
           Shell: bash v: 5.0.9 running in: yakuake inxi: 3.0.36 

Do you always have an internet connection when you start up? Shooting in the dark here, but a synchronous remote call might be the cause.

Try booting with the internet down or network down, might be something.

EDIT: Also welcome to the forums :slight_smile:

Hi, thank you for the welcome :slight_smile:

Worth a try. Internet is connected via ethernet but the connection is somewhat unstable from time to time. I'll keep you updated (since I don't know how to provoke the issue). But I'll do some tests when I come home.

Seems like something to try at least. Other thing is looking into the logs / journals for X11. I am not super clued up on that. You should be able to find articles. There is also a viewer in KDE/Plasma that you can use iirc.

Your shot in the dark hit well :slight_smile:.

Booted without any issues when the Ethernet cable was pulled out. Guess it has something to do with my network or pi-hole configuration which is running on another host.

The network manager behaved strangely while testing. There were issues opening the network managers widget. Moreover if I disabled automated connecting to the network, it just created a new connection after a reboot with automatic connection enabled. All those issues are gone after I changed my DNS to my ISPs DNS (not using Pi-Hole; don't know if Pi-Hole and it's configuration or the selected DNS is the culprit).

My temporary solution: Disable Pi-hole and use the ISP DNS-Server.

Thank you!

1 Like

Ah, good find, good attitude.

But this makes my heart cry. Please investigate further ... because noone wants to use ISP DNS.

[maybe you can help isolate it by forcing DNS change on the system]

I'm a little busy the next days. But I will definitely try to find a permanent solution and share it here. :slight_smile:

1 Like

Yaay! happy to be able to help!

Definitely not a systemic issue. I have a couple Manjaro KDE machines and they all go through a PiHole running on a RasPi without any problems.

I had a problem with long booting on kde too, didn't try to fix it, just switched to wm. If DE is booting too long out of the box, it's not ready to use i think. Had no problems with gnome and other DEs such deepin, pantheon, budgie.

Alright. I made some checks and it's definitely an unstable connection to the system running pi-hole (if connected by LAN-cable it seems to be stable. But the system usually is placed quite far away from my router). Have to think about another way to connect this machine to the network.
What I haven't found out is if it's plasmashell itself and what connection takes up so much time or if it is something I've installed.
Next step would probably be to check if this happens on a fresh install or on other KDE based distributions. Will do it but I can't tell you when this will happen :sweat_smile:

Try the live version, no reinstall necessary

Forum kindly sponsored by Bytemark