After upgrading to plasma-5.21.90, all krunner shortcuts stopped working. Some users report seeing duplicates in systemsettings, and removing the dups fixes the issue... I'll try that and report back.
Confirmed, I saw 2 entries in systemsettings->shortcuts for krunner, one with an icon one without I deleted the one without, and reset defaults for the other, and things work again. Fwiw, here's the diff of my ~/.config/kglobalshortcutsrc before and after the change: --- kglobalshortcutsrc.BAK 2021-05-19 09:13:52.814201471 -0500 +++ kglobalshortcutsrc 2021-05-19 09:15:32.288743607 -0500 @@ -62,11 +62,6 @@ next_active_tab=none,none,Next Active Tab toggle_mainwindow_visibility=none,none,Show/Hide Konversation -[krunner.desktop] -RunClipboard=Alt+Shift+F2,Alt+Shift+F2,Run command on clipboard contents -_k_friendly_name=KRunner -_launch=Alt+Space\tAlt+F2\tSearch,Alt+Space\tAlt+F2\tSearch,KRunner - [ksmserver] Halt Without Confirmation=none,none,Halt Without Confirmation Lock Session=Meta+L\tCtrl+Alt+L\tScreensaver,Meta+L\tCtrl+Alt+L\tScreensaver,Lock Session @@ -238,9 +233,9 @@ _launch=Meta+E,Meta+E,Dolphin [org.kde.krunner.desktop] -RunClipboard=,Alt+Shift+F2,Run command on clipboard contents +RunClipboard=Alt+Shift+F2,Alt+Shift+F2,Run command on clipboard contents _k_friendly_name=KRunner -_launch=\t\t,Alt+Space\tAlt+F2\tSearch,KRunner +_launch=Alt+F2\tAlt+Space\tSearch,Alt+Space\tAlt+F2\tSearch,KRunner [org.kde.plasma.emojier.desktop] _k_friendly_name=Emoji Selector
I suspect part of this was due to krunner.desktop being renamed to org.kde.krunner.desktop... in this commit ? https://invent.kde.org/plasma/plasma-workspace/-/commit/10d647c47a0d0cf14727679a0638a4055908c107
There is an update script that should fix this https://invent.kde.org/plasma/plasma-workspace/-/blob/master/krunner/update/krunnerglobalshortcuts.cpp Do you have an entry like [krunnerglobalshortcuts.upd] ctime=1621407975 done=5.17KRunnerGlobalShortcuts,5.22KRunnerGlobalShortcuts mtime=1621393778 in .config/kconf_udpaterc and is /usr/share/kconf_update/krunnerglobalshortcuts.upd on your system?
~/.config/kconf_udpaterc contains: [krunnerglobalshortcuts.upd] ctime=1621260782 mtime=1620912182 $ cat /usr/share/kconf_update/krunnerglobalshortcuts.upd Version=5 Id=5.22KRunnerGlobalShortcuts Script=krunnerglobalshortcuts
That means the update ẃas not run. Could you provide the times of creation and when krunnerglobalshortcuts.upd was last modified?
(In reply to David Redondo from comment #5) > That means the update ẃas not run. Could you provide the times of creation > and when krunnerglobalshortcuts.upd was last modified? I think at least, not sure why we have the times but not the "done" entry tbh. What happens if you run kconf_update --debug /usr/share/kconf_update/krunnerglobalshortcuts.upd kconf_update should be in the libexec dir on your system in a kf5 subfolder
FWIW I can reproduce this in the Wayland session but not the X11 session. $ cat /usr/share/kconf_update/krunnerglobalshortcuts.upd Version=5 Id=5.17KRunnerGlobalShortcuts Script=krunnerglobalshortcuts $ grep "krunnerglobalshortcuts.upd" -A 3 ~/.config/kconf_updaterc 156:[krunnerglobalshortcuts.upd] 157-ctime=1621259590 158-done=5.17KRunnerGlobalShortcuts,5.22KRunnerGlobalShortcuts 159-mtime=1620132570
(In reply to Nate Graham from comment #7) > FWIW I can reproduce this in the Wayland session but not the X11 session. This should make absolutely no difference. > $ cat /usr/share/kconf_update/krunnerglobalshortcuts.upd > Version=5 > Id=5.17KRunnerGlobalShortcuts > Script=krunnerglobalshortcuts This file is out of date but you probably have a newer one in your prefix? > $ grep "krunnerglobalshortcuts.upd" -A 3 ~/.config/kconf_updaterc > 156:[krunnerglobalshortcuts.upd] > 157-ctime=1621259590 > 158-done=5.17KRunnerGlobalShortcuts,5.22KRunnerGlobalShortcuts > 159-mtime=1620132570 Shows the update script run from your
Ah yeah, oops. cat ~/kde/usr/share/kconf_update/krunnerglobalshortcuts.upd Version=5 Id=5.22KRunnerGlobalShortcuts Script=krunnerglobalshortcuts
Hmm, now they are working for me again. I guess it's not this.
openQA sees a similar issue (X11. Wayland upgrades not tested): https://openqa.opensuse.org/tests/1774482#step/updates_packagekit_kde/1 The journal shows "No desktop file found for service krunner.desktop", so this is most likely related to this migration. Restarting kglobalaccel5 helped. Does the upgrade script maybe not apply to an already running kglobalaccel5?
Urgh
>oes the upgrade script maybe not apply to an already running kglobalaccel5 It needs kglobalaccel5 running, we are instructing it do the changes insted of changing the config file under its feet. What I find interesting that I saw no "Disabling desktop file" https://invent.kde.org/frameworks/kglobalaccel/-/blob/master/src/runtime/kserviceactioncomponent.cpp#L133 in the log which we should hit when we call KGlobalAccel::self()->cleanComponent (or do we not see debugs in openqa configuration?) Which I thought maybe KGlobalAccel::isComponentActive(oldDesktopFile) is maybe false if the file is not longer present but I could confirm that to be not the case.
A manual test: - move /usr/share/kglobalaccel/org.kde.krunner.desktop to /usr/share/kglobalaccel/krunner.desktop - qdbus org.kde.kglobalaccel /component/org_kde_krunner_desktop org.kde.kglobalaccel.Component.cleanUp (should return true) - restart kglobalaccel5 We are now in the initial situation when you are running plasma 5.21 - undo the move from the first step, to simulate the update to 5.22 - run [...]/kconf_update_bin/krunnerglobalshortcuts (kded should have run this in case of the upgrade) For me this transfers the shortcuts to the new correct org.kde.krunner.desktop component
(In reply to David Redondo from comment #14) > For me this transfers the shortcuts to the new correct > org.kde.krunner.desktop component but do not work indeed... They are marked as inactive when the QActions are destroyed
Fix for them being set to inactive https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/921
Git commit 6502f798fe64bd31f043fe2f273587e166ffcb52 by Nate Graham, on behalf of David Redondo. Committed on 09/06/2021 at 15:40. Pushed by ngraham into branch 'master'. krunnerglobalshortcuts: Prevent actions from becoming inactive If a QAction is destroyed, KGlobalAccel will automaticaly set it to inactive. To prevent this put them on the heap and intentionally leak them as it did before. M +13 -11 krunner/update/krunnerglobalshortcuts.cpp https://invent.kde.org/plasma/plasma-workspace/commit/6502f798fe64bd31f043fe2f273587e166ffcb52
Git commit 42b1039ed32c62e1d1750135cc5509caea6fe6b8 by Nate Graham, on behalf of David Redondo. Committed on 09/06/2021 at 15:46. Pushed by ngraham into branch 'Plasma/5.22'. krunnerglobalshortcuts: Prevent actions from becoming inactive If a QAction is destroyed, KGlobalAccel will automaticaly set it to inactive. To prevent this put them on the heap and intentionally leak them as it did before. (cherry picked from commit 6502f798fe64bd31f043fe2f273587e166ffcb52) M +13 -11 krunner/update/krunnerglobalshortcuts.cpp https://invent.kde.org/plasma/plasma-workspace/commit/42b1039ed32c62e1d1750135cc5509caea6fe6b8
Should be fully fixed with that. Please re-open if your KRunner shortcuts are still broken after upgrading to Plasma 5.22.1 and rebooting. Don't forget the reboot. :)
*** Bug 413368 has been marked as a duplicate of this bug. ***
Heads up, we have at least one downstream user reporting this issue persists with plasma-5.22.1, https://bugzilla.redhat.com/show_bug.cgi?id=1974589
FWIW, I had this issue after upgrading to Plasma 5.22.0 and Gear 21.04.2. A couple of day later I upgraded to Frameworks 5.83 and the problem was solved, so I didn't need to upgrade to Plasma 5.22.1 My O.S. is Slackware64 current (a.k.a. 15.0 beta).
(In reply to Rex Dieter from comment #21) > Heads up, we have at least one downstream user reporting this issue persists > with plasma-5.22.1, > > https://bugzilla.redhat.com/show_bug.cgi?id=1974589 At least openQA and my manual testing hasn't seen any issues with upgrades from 5.12, 5.18 and 5.21.5 anymore, so I don't think it's broken in general. Maybe there's some edge case with certain configs. Can you get kglobalshortcutsrc from the reporter?
Users are still reporting as unfixed, reopened. I'll direct them here to provide additional feedback, thanks.
No users have shown up to provide feedback. :( Given that it doesn't seem to be widely reproducible, without additional information, we won't be able to investigate further.
Sorry if it is the wrong place, but I've just upgraded to Kubuntu 21.10 from 21.04 and faced this bug. Plasma 4:5.22.5-0ubuntu1. Found 2 Krunner entries in keyboard shortcuts, one disabled and other with expected keys, reassigned - everything works now, but I still think that something is wrong with installation scripts and it should not be so, because this bug is not very easy to Google.
Still unresolved, just had a user report seeing this today in chat
Any ideas, Alexander or David?
I'll try to come up with reproducibility steps, iirc, it's not that hard to trigger this.
I am having this issue on Fedora 34. Shortcuts shows that both alt+space and alt+f2 should open krunner but they do not.
I have no idea since manual set up and OpenQa both worked. 5.22 is also EOL, so people who would be affected by this would be upgrading form 5.21 to 5.23 or later, not sure how common
(In reply to David Redondo from comment #31) > I have no idea since manual set up and OpenQa both worked. > 5.22 is also EOL, so people who would be affected by this would be > upgrading form 5.21 to 5.23 or later, not sure how common It looks like Fedora 34 is using 5.22.5 as of today. I can't speak to what is eol and what's not, but it seems that if even Fedora's current distro is impacted by this it is still relevant since very few users will be running something newer than that.
Broken in Kubuntu backports too Two krunner entries in system settings, both missing icons. Removed, but can't re add. It's very broken. Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-20-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-3230M CPU @ 2.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000
Work around is to add a manual custom shortcut, with the alt+space etc mappings, that just runs /usr/bin/krunner Not sure how something so simple and unchanged since forever gets busted.
I upgraded to Fedora 34 recently and following the same steps mentioned in Comment 1, made KRunner shortcuts work again. I remember being affected by Bug 413368 in Fedora 31.
5.22 is outdated any fix now won't help anything
For some reason this now started to fail in openQA tests which upgrade from 5.8/5.12/5.18 (Leap 42.x/15.x) -> 5.24 (Tumbleweed). First, kglobalacceld crashes and after the automatic restart the situation is as outlined in this report: Two entries in kglobalshortcutsrc which don't work. At least in openQA this looks like it's reproducible. Unfortunately I wasn't able to get a backtrace, but it seems to be heap corruption ("unaligned fastbin chunk detected"). The crash is not reproducible manually at least. This matches the arrival of Frameworks 5.97 in Tumbleweed. I can't tell how much 5.97.0 actually caused this or just exposed it more... CC Ahmad, who did the majority of changes in kglobalaccel 5.97.
(In reply to Fabian Vogt from comment #37) > For some reason this now started to fail in openQA tests which upgrade from > 5.8/5.12/5.18 (Leap 42.x/15.x) -> 5.24 (Tumbleweed). First, kglobalacceld > crashes and after the automatic restart the situation is as outlined in this > report: Two entries in kglobalshortcutsrc which don't work. At least in > openQA this looks like it's reproducible. Unfortunately I wasn't able to get > a backtrace, but it seems to be heap corruption ("unaligned fastbin chunk > detected"). The crash is not reproducible manually at least. > > This matches the arrival of Frameworks 5.97 in Tumbleweed. I can't tell how > much 5.97.0 actually caused this or just exposed it more... > > CC Ahmad, who did the majority of changes in kglobalaccel 5.97. It's actually fairly simple: kglobalacceld crashes when the kconf_update binary runs. With valgrind, the cause is obvious: void GlobalShortcutsRegistry::writeSettings() const { const auto &lst = GlobalShortcutsRegistry::self()->allMainComponents(); for (const KdeDGlobalAccel::Component *component : lst) { KConfigGroup configGroup(&_config, component->uniqueName()); if (component->allShortcuts().isEmpty()) { configGroup.deleteGroup(); delete component; } else { component->writeSettings(configGroup); } } _config.sync(); } That method destroys the component, but leaves it in the m_components vector of the shortcuts registry, i.e. it generates dangling pointers. This results in all kinds of fun, in particular double-, triple- and quadruple- frees each time writeSettings is called. I think it just worked by sheer luck when QHash was still used. Reverting that commit makes the immediate valgrind complaints stop, but it still crashes at some point later due to latent memory corruption. I think this explains the not fully reproducible issues prior to 5.97 well.
(In reply to Fabian Vogt from comment #38) > (In reply to Fabian Vogt from comment #37) > > For some reason this now started to fail in openQA tests which upgrade from > > 5.8/5.12/5.18 (Leap 42.x/15.x) -> 5.24 (Tumbleweed). First, kglobalacceld > > crashes and after the automatic restart the situation is as outlined in this > > report: Two entries in kglobalshortcutsrc which don't work. At least in > > openQA this looks like it's reproducible. Unfortunately I wasn't able to get > > a backtrace, but it seems to be heap corruption ("unaligned fastbin chunk > > detected"). The crash is not reproducible manually at least. > > > > This matches the arrival of Frameworks 5.97 in Tumbleweed. I can't tell how > > much 5.97.0 actually caused this or just exposed it more... > > > > CC Ahmad, who did the majority of changes in kglobalaccel 5.97. > > It's actually fairly simple: kglobalacceld crashes when the kconf_update > binary runs. With valgrind, the cause is obvious: "obvious" - ha! I wrote too soon. ~Component actually calls registry->takeComponent so it modifies m_components. The subtle addition of "&" in the QHash -> std::vector commit means that the container being iterated gets changed underneath the method. Just removing the "&" again doesn't fix the crash though, it just crashes differently, taking valgrind with it... Needs a closer look.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/57
(In reply to Bug Janitor Service from comment #40) > A possibly relevant merge request was started @ > https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/57 I tried it again from a clean slate and just removing the "&" fixed the issue completely, yay. Unfortunately that also means that it's unrelated to the remaining "shortcuts lost" issues and effectively I hijacked this bug report for something new...
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/58
Git commit 7347a904f1c97db7b7f7fcf49b6bdd34701c7737 by Fabian Vogt. Committed on 17/08/2022 at 17:14. Pushed by fvogt into branch 'master'. Avoid iterating a container while it's being mutated Otherwise the iterators get invalidated and weird stuff happens. M +2 -1 src/runtime/globalshortcutsregistry.cpp https://invent.kde.org/frameworks/kglobalaccel/commit/7347a904f1c97db7b7f7fcf49b6bdd34701c7737
*** Bug 458268 has been marked as a duplicate of this bug. ***
Was that enough to fix it, or do we need something else?
(In reply to Nate Graham from comment #45) > Was that enough to fix it, or do we need something else? The fix following comment 37 was for a regression in KF 5.97, so actually unrelated to the original report. I have no idea what the state of the original bug is after it was apparently not fully fixed (comment 21), I was never able to reproduce it and openQA doesn't see it either.
Ok, then let's close this since it seems like it's not clear that the original issue is indeed still a problem.
My KDE keyboard switching shortcuts started malfunctioning over the past one month… Before that it was fine. I'm using Kubuntu Jammy 22.04.1 with latest updates. Any idea when I can get this fixed on my system?
I note that there were reports that users were not reporting this issue. Reading through this bug I was able to fix my upgrade from Debian 11 to Debian 12. where the krunner shortcuts stopped working. It might be worth including a test / auto recover script and pushing it to the distros explicitly so that users with even less clue than me get an update to fix the problem. Thanks for all your great work /Andy Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-9-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz Memory: 15.6 GiB of RAM Graphics Processor: TAHITI Manufacturer: ASUS Product Name: All Series