When logging into a Plasma session on a system with kdeconnect (git 473a6c1) installed by default, the panels only appear after a long delay. The delay is long enough to use krunner to open gdb and attach to plasmashell, which gave me this backtrace: Thread 1 (Thread 0x7f0d5b8c7300 (LWP 2687)): #0 0x00007f0d547905dd in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f0d555c404b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5 #2 0x00007f0d55cbd83b in ?? () from /usr/lib64/libQt5DBus.so.5 #3 0x00007f0d55c7af9d in ?? () from /usr/lib64/libQt5DBus.so.5 #4 0x00007f0d55c6940b in QDBusConnection::call(QDBusMessage const&, QDBus::CallMode, int) const () from /usr/lib64/libQt5DBus.so.5 #5 0x00007f0d55c84f91 in QDBusAbstractInterface::callWithArgumentList(QDBus::CallMode, QString const&, QList<QVariant> const&) () from /usr/lib64/libQt5DBus.so.5 #6 0x00007f0d55c857a3 in QDBusAbstractInterface::call(QDBus::CallMode, QString const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&) () from /usr/lib64/libQt5DBus.so.5 #7 0x00007f0d55c8593d in QDBusAbstractInterface::call(QString const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&) () from /usr/lib64/libQt5DBus.so.5 #8 0x00007f0d55c6cc76 in QDBusConnectionInterface::startService(QString const&) () from /usr/lib64/libQt5DBus.so.5 #9 0x00007f0c84dac78c in DaemonDbusInterface::activatedService() () from /usr/lib64/libkdeconnectinterfaces.so.1 #10 0x00007f0c84dacabd in DaemonDbusInterface::DaemonDbusInterface(QObject*) () from /usr/lib64/libkdeconnectinterfaces.so.1 #11 0x00007f0c84db0e41 in DevicesModel::DevicesModel(QObject*) () from /usr/lib64/libkdeconnectinterfaces.so.1 #12 0x00007f0c84ff7590 in ?? () from /usr/lib64/qt5/qml/org/kde/kdeconnect/libkdeconnectdeclarativeplugin.so #13 0x00007f0d58693d6a in QQmlType::create(QObject**, void**, unsigned long) const () from /usr/lib64/libQt5Qml.so.5 #14 0x00007f0d586fe5c0 in ?? () from /usr/lib64/libQt5Qml.so.5 #15 0x00007f0d58701367 in ?? () from /usr/lib64/libQt5Qml.so.5 #16 0x00007f0d587015f9 in ?? () from /usr/lib64/libQt5Qml.so.5 #17 0x00007f0d586fe02f in ?? () from /usr/lib64/libQt5Qml.so.5 #18 0x00007f0d586fed8d in ?? () from /usr/lib64/libQt5Qml.so.5 #19 0x00007f0d587023ec in ?? () from /usr/lib64/libQt5Qml.so.5 #20 0x00007f0d58682915 in ?? () from /usr/lib64/libQt5Qml.so.5 #21 0x00007f0d586833ca in QQmlIncubationController::incubateFor(int) () from /usr/lib64/libQt5Qml.so.5 #22 0x00007f0d597cde5b in ?? () from /usr/lib64/libKF5Declarative.so.5 #23 0x00007f0d58683268 in QQmlEnginePrivate::incubate(QQmlIncubator&, QQmlContextData*) () from /usr/lib64/libQt5Qml.so.5 #24 0x00007f0d58680524 in QQmlComponent::create(QQmlIncubator&, QQmlContext*, QQmlContext*) () from /usr/lib64/libQt5Qml.so.5 #25 0x00007f0d597ca4d5 in KDeclarative::QmlObject::completeInitialization(QHash<QString, QVariant> const&) () from /usr/lib64/libKF5Declarative.so.5 #26 0x00007f0d5b2b826f in PlasmaQuick::AppletQuickItem::init (this=this@entry=0x55c2366786c0) at /usr/src/debug/plasma-framework-5.36.0git.20170728T114923~dcf08486f/src/plasmaquick/appletquickitem.cpp:558 #27 0x00007f0d1ce6b804 in AppletInterface::init (this=0x55c2366786c0) at /usr/src/debug/plasma-framework-5.36.0git.20170728T114923~dcf08486f/src/scriptengines/qml/plasmoid/appletinterface.cpp:157 #28 0x00007f0d5b2b96f8 in PlasmaQuick::AppletQuickItem::itemChange (this=0x55c2366786c0, change=QQuickItem::ItemSceneChange, value=...) at /usr/src/debug/plasma-framework-5.36.0git.20170728T114923~dcf08486f/src/plasmaquick/appletquickitem.cpp:805 #29 0x00007f0d5936328a in QQuickItemPrivate::itemChange(QQuickItem::ItemChange, QQuickItem::ItemChangeData const&) () from /usr/lib64/libQt5Quick.so.5 #30 0x00007f0d59367ce4 in QQuickItemPrivate::refWindow(QQuickWindow*) () from /usr/lib64/libQt5Quick.so.5 #31 0x00007f0d59368aa8 in QQuickItem::setParentItem(QQuickItem*) () from /usr/lib64/libQt5Quick.so.5 #32 0x00007f0d5936bc91 in ?? () from /usr/lib64/libQt5Quick.so.5 #33 0x00007f0d5936c1b3 in QQuickItem::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/libQt5Quick.so.5 #34 0x00007f0d5b2b9775 in PlasmaQuick::AppletQuickItem::qt_metacall (this=this@entry=0x55c2366786c0, _c=_c@entry=QMetaObject::WriteProperty, _id=<optimized out>, _a=_a@entry=0x7ffc3ec56680) Apparently it waits on a dbus call to reply.
I debugged a bit further and found the issue. Both /etc/xdg/autostart/kdeconnect.desktop org.kde.plasmashell.desktop are autostart phase 0, so they might be started in either order. If plasmashell is started first, it triggers the dbus-activation and kdeconnect is started by the session dbus-daemon. Then ksmserver starts /etc/xdg/autostart/kdeconnect.desktop, which locks up as it found that org.kde.kdeconnectd is already registered. Deleting /etc/xdg/autostart/kdeconnect.desktop helps and is likely the right solution here. However, this doesn't solve the problem entirely, as now kdeconnectd hangs inside the experimental bluetooth code: #0 0x00007f1ca5a1d5dd in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f1ca9c0504b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5 #2 0x00007f1ca88dc83b in QDBusPendingCallPrivate::waitForFinished() () from /usr/lib64/libQt5DBus.so.5 #3 0x00007f1ca837aab4 in isBluez5 () at bluez/bluez5_helper.cpp:74 #4 0x00007f1ca838d5d8 in QBluetoothServiceInfoPrivate::QBluetoothServiceInfoPrivate (this=0x560b034100a0) at qbluetoothserviceinfo_bluez.cpp:180 #5 0x00007f1ca835894e in QBluetoothServiceInfo::QBluetoothServiceInfo (this=0x560b03411b50) at qbluetoothserviceinfo.cpp:345 #6 0x00007f1cabc5411f in BluetoothLinkProvider::BluetoothLinkProvider() () from /usr/lib64/libkdeconnectcore.so.1 #7 0x00007f1cabc73042 in Daemon::Daemon(QObject*, bool) () from /usr/lib64/libkdeconnectcore.so.1 #8 0x0000560b01aff1a5 in ?? () #9 0x00007f1ca944446a in __libc_start_main () from /lib64/libc.so.6 #10 0x0000560b01aff24a in _start ()
If kdeconnect is already running, launching kdeconnectd again should just exit immediately. I'm not sure why this is not happening. Can you check if, while your desktop is already up, running kdeconnectd by hand also hangs? Or it does just exit as intended? I'm trying to understand if this happens always under your setup or just while the desktop is starting.
(In reply to Albert Vaca from comment #2) > If kdeconnect is already running, launching kdeconnectd again should just > exit immediately. I'm not sure why this is not happening. Can you check if, > while your desktop is already up, running kdeconnectd by hand also hangs? Or > it does just exit as intended? I'm trying to understand if this happens > always under your setup or just while the desktop is starting. It hangs as well, as expected. I rechecked, it's actually solely the bluetooth support's fault. Due to the blocking wait in BluetoothLinkProvider::BluetoothLinkProvider() the first instance does not answer to the pings sent by the second instance in time.
Why the heck is Bluetooth enabled is Suse packages?
(In reply to Albert Vaca from comment #4) > Why the heck is Bluetooth enabled is Suse packages? Only in the KDE:Unstable:Extra repositories for testing - which is a good thing as otherwise this bug wouldn't have been found :-)
Phase was delayed by this patch: commit 71bf898d466c5cb7df2d068721c5ff085983570c Author: David Edmundson <kde@davidedmundson.co.uk> Date: Tue Nov 28 11:53:50 2017 +0000 Delay kdeconnectd autostart phase Summary: This value maps to KAutostart::StartPhase kdeconnectd is certainly not BaseDesktop which is "essential desktop services" which is at the same level as plasmashell. This delays it into DesktopServices which is slightly later. For a user this won't change a thing, it'll still be loaded before ksplash is removed. Test Plan: None Differential Revision: https://phabricator.kde.org/D9031 Please reopen if the issue persists.