Summary: | kdeconnect delays Plasma start by over a minute | ||
---|---|---|---|
Product: | [Applications] kdeconnect | Reporter: | Fabian Vogt <fabian> |
Component: | plasmoid | Assignee: | Albert Vaca Cintora <albertvaka> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aleixpol, kishore96 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Fabian Vogt
2017-08-01 14:34:47 UTC
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. |