Latte-dock slow to start, random (infrequent) crashes


I return for help yet again with latte-dock.

I've searched for this issue. It's not that latte-dock doesn't start at login, but it takes a very long time to load. Sometimes it also crashes when I'm not paying attention. This is on a fresh install from the latest build 2022-01, last garuda-update was last night and again right before pulling the inxi -Faz.

However, the one thing I found that may be causing the issue are some problematic plugins, the only one of which I had been using until right now is Activity Pager. I switched to Activity Tab for the present.

What other plugins have you noticed that cause these issues? What plugins have you noticed you've been able to run fine on? Is there a thread like this elsewhere to reference? I haven't been able to even find an issues section of their github.

Delighted to hear from other users.

λ inxi -Faz
Kernel: 5.16.2-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=f6cccf9c-8580-435e-8f33-927e3e31bb2d rw [email protected]
quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
resume=UUID=2e9cba84-8fd3-4884-995e-6ac1c54716ad loglevel=3
Desktop: KDE Plasma 5.23.5 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11
vt: 1 dm: SDDM Distro: Garuda Linux base: Arch Linux
Type: Desktop System: Gigabyte product: X570 AORUS ELITE v: -CF
serial: <superuser required>
Mobo: Gigabyte model: X570 AORUS ELITE v: x.x
serial: <superuser required> UEFI: American Megatrends LLC. v: F34
date: 06/10/2021
ID-1: hidpp_battery_0 charge: 41% condition: N/A volts: 3.8 min: N/A
model: Logitech G502 LIGHTSPEED Wireless Gaming Mouse type: N/A
serial: <filter> status: Discharging
Info: model: AMD Ryzen 9 3950X bits: 64 type: MT MCP arch: Zen 2
family: 0x17 (23) model-id: 0x71 (113) stepping: 0 microcode: 0x8701021
Topology: cpus: 1x cores: 16 tpc: 2 threads: 32 smt: enabled cache:
L1: 1024 KiB desc: d-16x32 KiB; i-16x32 KiB L2: 8 MiB desc: 16x512 KiB
L3: 64 MiB desc: 4x16 MiB
Speed (MHz): avg: 3583 high: 4249 min/max: 2200/4761 boost: enabled
scaling: driver: acpi-cpufreq governor: performance cores: 1: 3496 2: 3592
3: 3596 4: 3595 5: 3601 6: 3672 7: 3695 8: 3393 9: 3596 10: 3593 11: 3599
12: 3586 13: 3392 14: 4249 15: 3400 16: 3393 17: 3510 18: 3585 19: 3594
20: 3596 21: 3592 22: 3607 23: 3569 24: 3407 25: 3587 26: 3589 27: 3591
28: 3583 29: 3408 30: 4249 31: 3355 32: 3398 bogomips: 223582
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional,
STIBP: conditional, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Device-1: NVIDIA TU104 [GeForce RTX 2070 SUPER] vendor: Micro-Star MSI
driver: nvidia v: 495.46 alternate: nouveau,nvidia_drm bus-ID: 0a:00.0
chip-ID: 10de:1e84 class-ID: 0300
Display: x11 server: X.Org compositor: kwin_x11 driver:
loaded: nvidia unloaded: modesetting alternate: fbdev,nouveau,nv,vesa
display-ID: :0 screens: 1
Screen-1: 0 s-res: 5120x1440 s-dpi: 108 s-size: 1204x342mm (47.4x13.5")
s-diag: 1252mm (49.3")
Monitor-1: DP-2 res: 2560x1440 dpi: 109 size: 597x336mm (23.5x13.2")
diag: 685mm (27")
Monitor-2: DP-4 res: 2560x1440 dpi: 109 size: 598x336mm (23.5x13.2")
diag: 686mm (27")
OpenGL: renderer: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
v: 4.6.0 NVIDIA 495.46 direct render: Yes
Device-1: YUAN High-Tech Development vendor: Corsair Memory driver: N/A
bus-ID: 06:00.0 chip-ID: 12ab:0380 class-ID: 0480
Device-2: NVIDIA TU104 HD Audio vendor: Micro-Star MSI
driver: snd_hda_intel v: kernel bus-ID: 0a:00.1 chip-ID: 10de:10f8
class-ID: 0403
Device-3: AMD Starship/Matisse HD Audio vendor: Gigabyte
driver: snd_hda_intel v: kernel bus-ID: 0c:00.4 chip-ID: 1022:1487
class-ID: 0403
Device-4: Texas Instruments ATH-G1WL type: USB
driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-3.1.4:8
chip-ID: 0451:16ba class-ID: 0300 serial: <filter>
Sound Server-1: ALSA v: k5.16.2-zen1-1-zen running: yes
Sound Server-2: PulseAudio v: 15.0 running: no
Sound Server-3: PipeWire v: 0.3.43 running: yes
Device-1: Intel I211 Gigabit Network vendor: Gigabyte driver: igb v: kernel
port: f000 bus-ID: 05:00.0 chip-ID: 8086:1539 class-ID: 0200
IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
IF-ID-1: wg-mullvad state: unknown speed: N/A duplex: N/A mac: N/A
Local Storage: total: 4.57 TiB used: 474.64 GiB (10.1%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:2 vendor: A-Data model: SX6000PNP
size: 953.87 GiB block-size: physical: 512 B logical: 512 B
speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: V9002s85
temp: 36.9 C scheme: GPT
ID-2: /dev/nvme1n1 maj-min: 259:0 vendor: Western Digital
model: WDS100T1XHE-00AFY0 size: 931.51 GiB block-size: physical: 512 B
logical: 512 B speed: 63.2 Gb/s lanes: 4 type: SSD serial: <filter>
rev: 614600WD temp: 42.9 C scheme: GPT
ID-3: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 1TB
size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
type: SSD serial: <filter> rev: 4B6Q scheme: GPT
ID-4: /dev/sdb maj-min: 8:16 vendor: Western Digital
model: WD20EARX-00ZUDB0 size: 1.82 TiB block-size: physical: 4096 B
logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 5400 serial: <filter>
rev: 0A80 scheme: GPT
ID-1: / raw-size: 896.73 GiB size: 896.73 GiB (100.00%)
used: 28.33 GiB (3.2%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
used: 576 KiB (0.2%) fs: vfat dev: /dev/sda1 maj-min: 8:1
ID-3: /home raw-size: 896.73 GiB size: 896.73 GiB (100.00%)
used: 28.33 GiB (3.2%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-4: /var/log raw-size: 896.73 GiB size: 896.73 GiB (100.00%)
used: 28.33 GiB (3.2%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-5: /var/tmp raw-size: 896.73 GiB size: 896.73 GiB (100.00%)
used: 28.33 GiB (3.2%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 31.35 GiB used: 256 KiB (0.0%)
priority: 100 dev: /dev/zram0
ID-2: swap-2 type: partition size: 34.49 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/sda3 maj-min: 8:3
System Temperatures: cpu: 33.0 C mobo: 30.0 C gpu: nvidia temp: 43 C
Fan Speeds (RPM): N/A gpu: nvidia fan: 24%
Processes: 573 Uptime: 5m wakeups: 2 Memory: 31.35 GiB
used: 3.15 GiB (10.1%) Init: systemd v: 250 tool: systemctl Compilers:
gcc: 11.1.0 clang: 13.0.0 Packages: pacman: 1908 lib: 525 Shell: fish
v: 3.3.1 default: Bash v: 5.1.16 running-in: konsole inxi: 3.3.12

My problems with Latte got solved by switching to Icons-only Task Manager.Highly recommended.

1 Like

Happened to me out of nowhere starting a few weeks ago. After a specific update. I had to delay the start of Conky by 20sec otherwise it was taking the top bar space thinking nothing was there.

I changed from git version to normal version (you might want to try a switch from one to the other), seemed to help, but not really in the end. Played with a few things around like network, VPN, etc... after a while it stopped taking 20sec to load and started loading as quick as before.

I don't know if I fixed the issue or if it got fixed by package update. Seems to vary from time to time from machine to machine. On another machine it's the Background Opacity When Touching Windows that works erratic and most of the time remains opaque even though no window touches it.

So it seems a bit more unstable, on my machines, then it used to be a few months ago....

It wouldnt be a surprise if conky transparent window is considered as the window touching the latte panel or dock. Didnt you try to close conky?

@psifidotos are you replying to me or to OP?
If to me, happens even without running conky.

1 Like

If to me, I have not tried this yet. Switching activity tab plugin resolved my issue. If it pops up in this context I will definitely try!

Yes i'm sure i want to revive this since it's unresolved. I think i figured out what might be doing it...

When I removed some plasma widgets (i had a calendar at the top) latte-dock stopped crashing for a bit. I then noticed this weird transparent object inserting itself a the top, and just like that latte crashed again. Here's a screenshot, i made my background white so you could see:

Anyone have any idea what the heck this is? The rounded corner transparent whatever at the top of the screen? I think latte dock doesn't like plasma widgets or any other transparent things touching it.

That transparent thing at the top looks like latte dock/panel itself. Might sound crazy but is it possible that latte is already running and any other instances of latte will crash after a while? Maybe change some setting of latte (more specifically make sure the top bar isn't on autohide)?

1 Like

That is the Screen Edge (System Settings->Workspace Behavior->Desktop Effects->Screen Edge).

I had a problem after an update just about a month ago, it stopped allowing me to arrange icons unless I specifically went in to edit mode. I reset the Latte config with Garuda Assistant, then restored a backup of Dr460nized.layout.latte and haven't had an issue again...yet.


I came across this exact same issue in Arch forum, so i tried ps aux | grep latte and no other instances were running, just grep latte. I still ran killall latte-dock after that just to be sure.

When it launches, and from reading some of the logs i see (both nohup.out and crash dumps), it looks like when i launch it, it tries to launch itself several times.

I notice when it lasts the longest is when it's in "busy mode", that is to say, when it is not trying to render any transparency because it detects a window nearby (a default setting).

I plugged it into kde bug system: 458906 – Latte dock crashes at startup and at random intervals


I missed this part. It's not on auto-hide. However, i do have it set to mind when windows are nearby it. I like that behavior too much to give it up i think, because if i saw my background with a window maximized, the apparent gap would bother me. The bottom dock is indeed autohide when there is a window on top of it, but i don't think the bottom dock is the one responsible for the crash. I can move windows near it and it'll autohide just fine. It may be when the top bar is trying to transition from fully transparent to opaque or translucent because there's a plasma widget or the screen edge thing mentioned nearby.

1 Like

ok, i deleted the latte config directory (i keep backups on my NAS), and reinstalled latte and starting with a fresh config. I disabled the screen edge effect. Let's give this a few hours or days and see what happens...

I was just sharing that I had an issue with it lately, though from the outside most would probably say self inflicted, since install though all I do is pin/unpin and move icons on the bottom dock.

I hope it helps, or at a minimum gives you more insight into what might be causing your issue.

1 Like

So i uninstalled cairo-dock and cleared a bunch of plasma widgets... turned off the screen edge thing as indicated.

There are MUCH less frequent crashes, but they still persist especially at startup. SO those things made them less frequent, but there's still something causing it to crash. I don't want to have to give up latte dock again! I do love it. xD

1 Like

Same feeling here :smiley:


Have you tried switching themes and/or selectively disabling some of KDE's desktop effects?


Something to note as menu has reportedly being giving users issues (lag, crashes, etc.), so you could also try removing the global menu applet and see if you still have any issues after that. I do realize that you're giving up a lot by removing global menu applet, but it would be good to know if that's maybe causing your frequent crashes...

...and when I say remove global menu applet, I mean just remove it from latte top bar....

Just the screen edge indicator. I can try that if crashes persist.

Do you mean the Window AppMenu? That'll be the next thing i try i suppose, it's easy to remove even if it is ... necessary in some applications. I think pycharm without it will be the death of me. :sweat_smile: