SUMMARY plasmawindowed takes a very long time to show a window. STEPS TO REPRODUCE 1. Start a Sway WM session from SDDM 2. Open a terminal and execute `plasmawindowed org.kde.plasma.networkmanagement` 3. Wait OBSERVED RESULT Immediately after start the following is printed: qt5ct: using qt5ct plugin org.kde.plasmaquick: Applet preload policy set to 1 Then nothing happens for a long time (approx 30s). Then the following is printed: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") Again nothing happens for a long time (another 30s?). Then the following is printed and the window appears at approximately the same time: org.kde.plasma: requesting config for "Networks" without a containment! qml: 0 DBusMenu disabled for this application EXPECTED RESULT The window appears immediately. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2 Kernel Version: 5.6.4 OS Type: 64-bit Processors: 8 × AMD Ryzen 5 2400G with Radeon Vega Graphics Memory: 13.5 GiB of RAM Sway WM Version: 1.4 ADDITIONAL INFORMATION Other KDE applications also take a long time to start. I most notably remember Okular taking its time to start. KMail on the other hand starts almost instantly.
From your sway session can you run qdbus org.kde.kglobalaccel and report back 1) what it shows 2) if it replies immediately or after 30s it's an interesting case: - kglobalaccell won't work on X - on kwin waland it'll be registered by our compositor on sway, I would expect that we: start kglobalaccel, exit, reply with an error immediately, but I'm not sure.
(In reply to David Edmundson from comment #1) > From your sway session can you run > > qdbus org.kde.kglobalaccel > > and report back > > 1) what it shows > 2) if it replies immediately or after 30s ❯ time qdbus org.kde.kglobalaccel Error: org.freedesktop.DBus.Error.NoReply Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ________________________________________________________ Executed in 24.92 secs fish external usr time 8.75 millis 456.00 micros 8.29 millis sys time 0.11 millis 106.00 micros 0.00 millis > it's an interesting case: > - kglobalaccell won't work on X > - on kwin waland it'll be registered by our compositor > > on sway, I would expect that we: > start kglobalaccel, exit, reply with an error immediately, but I'm not sure. ❯ pgrep kglobalaccel Returns no results / non-zero exit status, i.e. there is no process with that name.
Maybe helpful: ● dbus-broker.service - D-Bus User Message Bus Loaded: loaded (/usr/lib/systemd/user/dbus-broker.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2020-04-18 11:34:01 CEST; 8h ago TriggeredBy: ● dbus.socket Docs: man:dbus-broker-launch(1) Main PID: 2059 (dbus-broker-lau) Tasks: 2 (limit: 16473) Memory: 16.1M CPU: 37.212s CGroup: /user.slice/user-1000.slice/user@1000.service/dbus-broker.service ├─2059 /usr/bin/dbus-broker-launch --scope user └─2060 dbus-broker --log 4 --controller 10 --machine-id ... --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 ... dbus-broker-launch[2059]: Service file '/usr/share/dbus-1/services/org.kde.kscreen.service' is not named after the D-Bus name 'org.kde.KScreen'. ... dbus-broker-launch[2059]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored ... dbus-broker-launch[2059]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored ... dbus-broker-launch[2059]: Service file '/usr/share/dbus-1/services/fr.emersion.mako.service' is not named after the D-Bus name 'org.freedesktop.Notifications'. ... dbus-broker-launch[2059]: Service file '/usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service' is not named after the D-Bus name 'org.freedesktop.FileManager1'. ... dbus-broker-launch[2059]: Service file '/usr/share/dbus-1/services/org.kde.plasma.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'. ... dbus-broker-launch[2059]: Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share/dbus-1/services/org.kde.plasma.Notifications.service' ... dbus-broker-launch[2059]: Service file '/usr/share/dbus-1/services/org.kde.baloorunner.service' is not named after the D-Bus name 'org.kde.runners.baloo'. ... systemd[1229]: Started D-Bus User Message Bus. ... dbus-broker-lau[2059]: Ready
We've seen on some systems if a systemd service fails to start N times quickly systemd blocks re-startup the next call then times out as Dbus is unaware that's what's happening. Why it wasn't starting is a setup issue, so now the cause is known I don't intend to work on it.