Plasma takes over a minute to load

Tried Neon Testing, neon-testing-20240207-1524.iso, as a VM guest…

Seems to be a 25 second delay before the panel appears (wallpaper might appear earlier or not, that seems to depend on whether you are logging with X or Wayland).

Updating to the state 2024/02/26 made no difference to the delay.

Journalctl shows a pause and a failure:

[system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)

It doesn’t matter whether Bluetooth is activated in Background Services or not…

1 Like

journalctl -g ‘service_start_timeout=25000ms’

– Boot 3d52c81a35264e4d9ef9cdd3f498d216 –
фев 27 07:57:32 neo dbus-daemon[963]: [system] Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)
фев 27 07:57:32 neo kded6[1687]: kf.bluezqt: PendingCall Error: “Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)”
фев 27 07:57:57 neo dbus-daemon[963]: [system] Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)
фев 27 08:02:50 neo dbus-daemon[963]: [system] Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)

There’s a bug logged here…
https://bugs.kde.org/show_bug.cgi?id=481870

1 Like

I’m not sure if my issue is related to bluetooth. I did notice that:

Reloading plasmashell takes just a few seconds
Reloading kwin_x11 takes a full minute

That sounds like a different issue.

Yeah, it’s weird. Copying .config and .local wholesale to a new user account and that user loads in about 5 seconds, while my user account takes over a minute.

I did double check bluetooth, and it’s fully disabled with no adapters

What about systemd-analyze --user blame?
Could be an old leftover service or something you forgot about starting up on your “old” user.

The user services are usually in ~/.config/systemd/user, but you never know.
A symlink can go anywhere.

You can also compare the ~/.bashrc & ~/.bash_profile files if there are any difference between the old and new user.

I have read about for example ssh-agent making things acting strange if you start it at login.

Hi ! I solved the problem by deactivating the start screen.

I had the same issue when I upgraded to Plasma 6.0.

I fixed it by removing widgets that were incompatible with 6.0.

Also, kscreen-doctor appears to not work. Running ‘kscreen-doctor -o’ seems to hang indefinitely. One of my widgets ran this command, so that could have been my issue, but several other widgets weren’t working.

@bedna The longest blame is 1.5 seconds. That folder doesn’t exist in either profile.

ssh-agent isn’t causing issues as far as I can tell, just kglobalaccell and xorg

@Junakreiter Tried that, and it had no effect for me on either profile

@bedtime This is Debian 12’s plasma 5.x, and given my alt profile loads just fine with the same setup, I think your issue is different

It won’t - that tool essentially stops at graphical target - which is when you see SDDM.

After that point you need to look at the journal and (for X11 stuff, /var/log/Xorg.0.log)

p.s. plot instead of blame is a better go to for startup delays as you can see how the delays interact with other things.

Not if he did what I told him earlier, to use the --user option.

Hadn’t spotted your mention of it .

Yeah, --user blame captures user info past graphical target, but still doesn’t capture the times / delays of all services (just like the plain version, it misses “simple” services), and if one of them is the cause, people might incorrectly discount a service as the root of the issue

1 Like

Yes, I used --user

I did a gdb backtrace of kglobalaccel, and for the first 30 seconds or so, I see this:

[New LWP 8964]
[New LWP 8968]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7fff698026f8) at ./nptl/futex-internal.c:57
57      ./nptl/futex-internal.c: No such file or directory.
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7fff698026f8) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fff698026f8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#2  0x00007f27e3aa4efb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7fff698026f8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007f27e3aa7558 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5579c26c9bf8, cond=0x7fff698026d0) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7fff698026d0, mutex=mutex@entry=0x5579c26c9bf8) at ./nptl/pthread_cond_wait.c:618
#5  0x00007f27e3393ee6 in _xcb_conn_wait (c=c@entry=0x5579c26c9be0, cond=cond@entry=0x7fff698026d0, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:476
#6  0x00007f27e3395d8f in wait_for_reply (c=c@entry=0x5579c26c9be0, request=request@entry=3369973, e=e@entry=0x7fff69802750) at ../../src/xcb_in.c:522
#7  0x00007f27e3395fbc in xcb_request_check (c=0x5579c26c9be0, cookie=...) at ../../src/xcb_in.c:756
#8  0x00007f27e012bc3b in KGlobalAccelImpl::grabKey (this=0x5579c27ff620, keyQt=218103828, grab=true) at ./src/runtime/plugins/xcb/kglobalaccel_x11.cpp:239
#9  0x00007f27e4b88e72 in GlobalShortcutsRegistry::registerKey (this=0x7f27e4b98140 <(anonymous namespace)::Q_QGS__self::innerFunction()::holder>, key=..., shortcut=shortcut@entry=0x5579c284de70) at ./src/runtime/globalshortcutsregistry.cpp:473
#10 0x00007f27e4b85070 in GlobalShortcut::setActive (this=0x5579c284de70) at ./src/runtime/globalshortcut.cpp:183
#11 0x00007f27e4b85990 in GlobalShortcut::setActive (this=<optimized out>) at ./src/runtime/globalshortcut.cpp:176
#12 0x00007f27e4b82211 in Component::activateShortcuts (this=<optimized out>) at ./src/runtime/component.cpp:94
#13 0x00007f27e4b86e15 in GlobalShortcutsRegistry::activateShortcuts (this=<optimized out>) at ./src/runtime/globalshortcutsregistry.cpp:128
#14 GlobalShortcutsRegistry::grabKeys (this=<optimized out>) at ./src/runtime/globalshortcutsregistry.cpp:445
#15 0x00007f27e4b7e35c in KGlobalAccelInterface::grabKeys (this=this@entry=0x5579c27ff620) at ./src/runtime/kglobalaccel_interface.cpp:46
#16 0x00007f27e012ad20 in KGlobalAccelImpl::x11MappingNotify (this=this@entry=0x5579c27ff620) at ./src/runtime/plugins/xcb/kglobalaccel_x11.cpp:327
#17 0x00007f27e012b138 in KGlobalAccelImpl::nativeEventFilter (this=0x5579c27ff620, eventType=..., message=0x7f27d80327b0) at ./src/runtime/plugins/xcb/kglobalaccel_x11.cpp:283
#18 0x00007f27e3eaec7f in QAbstractEventDispatcher::filterNativeEvent (this=<optimized out>, eventType=..., message=message@entry=0x7f27d80327b0, result=result@entry=0x7fff69802ad8) at kernel/qabstracteventdispatcher.cpp:495
#19 0x00007f27dfb8d40f in QXcbConnection::handleXcbEvent (this=this@entry=0x5579c26c71e0, event=event@entry=0x7f27d80327b0) at ./src/plugins/platforms/xcb/qxcbconnection.cpp:579
#20 0x00007f27dfb8eab6 in QXcbConnection::processXcbEvents (this=0x5579c26c71e0, flags=...) at ./src/plugins/platforms/xcb/qxcbconnection.cpp:1063
#21 0x00007f27dfbb4ec3 in xcbSourceDispatch (source=<optimized out>) at ./src/plugins/platforms/xcb/qxcbeventdispatcher.cpp:103
#22 0x00007f27e2c627a9 in g_main_dispatch (context=0x7f27d8005010) at ../../../glib/gmain.c:3454
#23 g_main_context_dispatch (context=context@entry=0x7f27d8005010) at ../../../glib/gmain.c:4172
#24 0x00007f27e2c62a38 in g_main_context_iterate (context=context@entry=0x7f27d8005010, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4248
#25 0x00007f27e2c62acc in g_main_context_iteration (context=0x7f27d8005010, may_block=1) at ../../../glib/gmain.c:4313
#26 0x00007f27e3f09836 in QEventDispatcherGlib::processEvents (this=0x5579c27e6200, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#27 0x00007f27e3eb017b in QEventLoop::exec (this=this@entry=0x7fff69802d60, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#28 0x00007f27e3eb82d6 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#29 0x00007f27e4330e8c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1863
#30 0x00005579c1c0061f in main (argc=<optimized out>, argv=<optimized out>) at ./src/runtime/main.cpp:99
[Inferior 1 (process 8882) detached]

journactl logs show:

# I login at 00:30:00
...snip fairly quick stuff
Mar 11 00:30:12 debian systemd[1]: user-113.slice: Consumed 3.919s CPU time.
Mar 11 00:30:14 debian kalendarac[40354]: org.kde.pim.akonadicore: Creating agent instance failed for  "/usr/share/akonadi/firstrun/defaultaddressbook"
Mar 11 00:30:27 debian plasmashell[40103]: QObject::connect: No such slot DesktopProtocol::_k_slotRedirection(KIO::Job *, QUrl)
Mar 11 00:30:29 debian kalendarac[40524]: QObject::connect: No such signal QDBusAbstractInterface::resumingFromSuspend()
Mar 11 00:30:29 debian plasmashell[39984]: qt.qpa.clipboard: QXcbClipboard::setMimeData: Cannot set X11 selection owner
Mar 11 00:30:29 debian plasmashell[39984]: qt.qpa.clipboard: QXcbClipboard::setMimeData: Cannot set X11 selection owner
Mar 11 00:30:29 debian kalendarac[40527]: QObject::connect: No such signal QDBusAbstractInterface::resumingFromSuspend()
Mar 11 00:30:29 debian kalendarac[40533]: QObject::connect: No such signal QDBusAbstractInterface::resumingFromSuspend()
Mar 11 00:30:29 debian kdeconnectd[40337]: kdeconnect.core: Could not query capabilities from notifications server
Mar 11 00:30:29 debian kalendarac[40539]: QObject::connect: No such signal QDBusAbstractInterface::resumingFromSuspend()
... snip a lot of kalendarac akondai stuff...
Mar 11 00:30:29 debian kalendarac[40444]: org.kde.pim.akonadiserver: Subscriber Akonadi::Server::NotificationSubscriber(0x7f280023e270) identified as "KNotes Session - 94014923681936"

# Note the pause here

Mar 11 00:30:49 debian dbus-daemon[3119]: [system] Activating service name='org.kde.powerdevil.chargethresholdhelper' requested by ':1.257' (uid=1000 pid=40005 comm="/usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdev") (using servicehelper)
Mar 11 00:30:49 debian kded5[39931]: Installing the delayed initialization callback.
Mar 11 00:30:49 debian kalarmautostart[43518]: kf.notifications: env says KDE is running but SNI unavailable -- check KDE_FULL_SESSION and XDG_CURRENT_DESKTOP
...
... snip more kded5 init...
...
Mar 11 00:30:49 debian org_kde_powerdevil[40005]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getthreshold failed "Charge thresholds are not supported by the kernel for this hardware"

# Long pause....

Mar 11 00:31:03 debian dbus-daemon[3119]: [system] Activating service name='org.kde.kded.smart' requested by ':1.272' (uid=1000 pid=39931 comm="/usr/bin/kded5") (using servicehelper)
Mar 11 00:31:03 debian dbus-daemon[3119]: [system] Successfully activated service 'org.kde.kded.smart'
and the rest of stuff happening in the next few seconds

Comparing to the working user, Nothing really changes in the logs except for the timestamps/interleaving

I just had this happen several times in the middle of the session. X froze for about a minute, and kglobalaccel5 and xor were taking up a combined 100% cpu.

Here is the kgloablaccel backtrace:


Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f27e3b1b15f in __GI___poll (fds=0x5579c285af20, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
#0  0x00007f27e3b1b15f in __GI___poll (fds=0x5579c285af20, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f27e2c629ae in g_main_context_poll (priority=<optimized out>, n_fds=3, fds=0x5579c285af20, timeout=<optimized out>, context=0x7f27d8005010) at ../../../glib/gmain.c:4553
#2  g_main_context_iterate (context=context@entry=0x7f27d8005010, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4243
#3  0x00007f27e2c62acc in g_main_context_iteration (context=0x7f27d8005010, may_block=1) at ../../../glib/gmain.c:4313
#4  0x00007f27e3f09836 in QEventDispatcherGlib::processEvents (this=0x5579c27e6200, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#5  0x00007f27e3eb017b in QEventLoop::exec (this=this@entry=0x7fff69802d60, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#6  0x00007f27e3eb82d6 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#7  0x00007f27e4330e8c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1863
#8  0x00005579c1c0061f in main (argc=<optimized out>, argv=<optimized out>) at ./src/runtime/main.cpp:99

Hmm, I can sometimes trigger a kwin crash via wobbly windows, and recovering from that this same kglobalaccel5 thing eats up several 1 minute blocks

gqrx launch and closing can also cause the 1 minute delay, also via kglobalaccel5+xorg