Bug 411326 - krunner hangs on first start
Summary: krunner hangs on first start
Status: RESOLVED WORKSFORME
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.16.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Alexander Lohnau
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-26 17:28 UTC by Lioh
Modified: 2021-01-08 04:34 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
strace created while krunner hangs. (170.70 KB, text/plain)
2019-08-26 17:28 UTC, Lioh
Details
krunner plugins (80.80 KB, image/png)
2019-09-15 20:25 UTC, Ricardo J. Barberis
Details
krunner plugins 2 (58.63 KB, image/png)
2019-09-15 20:26 UTC, Ricardo J. Barberis
Details
krunner 5.19.3 on neon (1.93 MB, text/plain)
2020-07-22 05:51 UTC, Arek Guzinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lioh 2019-08-26 17:28:22 UTC
Created attachment 122374 [details]
strace created while krunner hangs.

SUMMARY
When I try to launch krunner the first time after every login, the application does not allow me to enter text in the input box. It takes about 3-5 minutes for krunner to come in a working state.

Afterwards it works perfectly. I have disabled baloo on my system but Plasma Search is still active for all default modules.

STEPS TO REPRODUCE
1. log in
2. start krunner using Alt+F2
3. try to type something in the input box

OBSERVED RESULT
krunner hangs for quite a long while

EXPECTED RESULT
krunner should allow me to enter search terms directly

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Slackware -current
(available in About System)
KDE Plasma Version:  5.16.3
KDE Frameworks Version:  5.61.0
Qt Version: 5.13.0

ADDITIONAL INFORMATION
Comment 1 Ricardo J. Barberis 2019-09-15 20:25:57 UTC
Created attachment 122675 [details]
krunner plugins

Can't reproduce on same distro and versions, neither after upgrading to Plasma 5.16.5, Frameworks 5.62, Applications 19.08.1

For reference I'm attaching 2 screenshots showing my krunner plugins.
Comment 2 Ricardo J. Barberis 2019-09-15 20:26:29 UTC
Created attachment 122676 [details]
krunner plugins 2
Comment 3 Lioh 2019-09-16 05:51:03 UTC
It is definitly related to Plasma Search plugins. I have set them to default (which is nearly everything is enabled) and the issue occurs. Can you try to enable all plugins and test again?

I have also noticed that clicking on the configuration icon for plasma search modules in krunner takes about 2 minutes till the dialog is opened.
Comment 4 Lioh 2019-09-16 05:56:38 UTC
In the meanwhile I could nail it down to the instant messenger / telepathy plugin.
Comment 5 Ricardo J. Barberis 2019-09-17 02:35:15 UTC
Cool!

And this might be a Slackware-only issue, it'd be nice to know what happens in some other distros.

Unfortunately I can't test if it's telepathy, since yesterday I completely removed ktp-* and telepathy-* from my system, as I never used them.
Comment 6 Martin Droessler 2020-04-28 07:43:41 UTC
(In reply to Lioh from comment #4)
> In the meanwhile I could nail it down to the instant messenger / telepathy
> plugin.

I encountered the same issue with krunner and after reading your comment, I searched for configuration-options in systemsettings. The module for krunner also took ages to load, and indeed contained a submodule for telepathy. After checking dmesg it shows me:

> dbus-daemon[1380]: [session uid=1000 pid=1380] Failed to activate service 'org.freedesktop.Telepathy.Client.KTp.KdedIntegrationModule': timed out (service_start_timeout=120000ms)

I disabled the submodule and also removed the packages "telepathy-kde-contact-runner" and "telepathy-kde-integration-module" - will see if that helps after the next reboot.

Oh, and btw: I use Arch ;-)
Comment 7 Yichao Yu 2020-04-29 01:39:53 UTC
I'm not sure if it is exactly the same issue as originally reported but I've experienced the same issue as Martin Droessler on ArchLinux after a recent upgrade to 20.04.0. It is definately caused by ktp-contact-runner or one of it's dependencies.

Using a combination of debugger and dbus inspection the hang is in `KTp::GlobalPresence::GlobalPresence (ktp-common-internals/KTp/global-presence.cpp)` which did a synchrnous call to `org.freedesktop.Telepathy.Client.KTp.KdedIntegrationModule`. The destination is not owned by any process on my computer probably because I'm not using ktp and it only returns after few second when the dbus call timed out.
Comment 8 Claudius 2020-04-29 13:26:34 UTC
I had the same Problem. I opened the KRunner settings 'kcmshell5 kcm_plasmasearch' (those also hang for a long time) unchecked "Instant Messaging" hit "Apply" and everything went back to normal (except opening the settings window). No need for a reboot or logout.

Settings printed this to stderr: 'QObject::connect: No such signal QDBusAbstractInterface::statusChange(QString)'
I am not sure if related.
Comment 9 Daniel Vrátil 2020-04-30 08:47:23 UTC
There's no trivial way to make the DBus call in ktp-contact-runner asynchronous so that it does not block KRunner when KTP service is not running. This is due to how KDE Telepathy, and Telepthy itself for that matter, are designed.

If you don't use KTP, just uninstall the package that provides the ktp-contact-runner plugin, or disable the runner in KRunner settings.
Comment 10 Yichao Yu 2020-04-30 15:11:38 UTC
Uninstalling or disabling is the workaround now. However it shouldn’t be the permanent solution. There are so many different made application packages (which is great on itself) and remembering what to install is next to impossible. If the disk space is not a problem (very common these days) I just use meta packages to install all of them and doing less than that actually requires installing more packages manually.

It is also very hard for a non programmer to figure out what is wrong leading to very bad user experience.

As for a fix, it seems that the issue is just that the iced integration module doesn’t register the dubs interface before ktp is loaded and ready. If as you said the client side can’t be made asynchronous easily and since I believe KDE fully control *this* interface, can the dubs interface be made available unconditionally and make anything that rely on defecting the availability of this interface based on making a call on this interface again? The client would still not be very robust this way and I still think that’ll be good to fix but at least the server won’t be messing with it by default.
Comment 11 Claudius 2020-05-08 10:15:46 UTC
The problem seems to be solved on my Arch install after updating to 5.18.5. Neither the Krunner settings nor Krunner itself hang regardless of selected plugins.
Comment 12 Alexander Lohnau 2020-07-08 12:52:38 UTC
Does anyone still have this problem? Otherwise I would suggest marking this bug as resolved.
Comment 13 Arek Guzinski 2020-07-22 05:50:51 UTC
I got this bug since i upgraded to 5.19.3 (nope - did not have that before...)
on KDE neon.

Disabling the telepathy plugin fixed it (not sure why it was enabled anyway - I don't need it).

The behavior was a little different though:
* krunner would krash after some time of hanging - I measured ~15 and ~45 seconds.
* it's not usable even an hour after login.

I'll attach a strace dump.
Comment 14 Arek Guzinski 2020-07-22 05:51:56 UTC
Created attachment 130310 [details]
krunner 5.19.3 on neon
Comment 15 Alexander Lohnau 2020-07-22 06:28:41 UTC
Thank you for the additional information! I will look into it.
Comment 16 Alexander Lohnau 2020-07-28 12:16:01 UTC
Unfortunately I can not reproduce, but I have made a change to run the init method call async.
Could you/anyone else with this problen please check if https://invent.kde.org/network/ktp-contact-runner/commit/170bbcdb4c33030ae4b94ce12345594f131c40de fixes this issue.
Comment 17 Justin Zobel 2020-11-22 04:01:37 UTC
Can those affected please test with Alexander's commit in Comment 16?

I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
Comment 18 Bug Janitor Service 2020-12-07 04:34:13 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 19 Arek Guzinski 2020-12-08 15:03:06 UTC
With the following versions...
Operating System: KDE neon 5.20
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2

... I can't reproduce the Bug anymore :) (yep, I switched Instant Messeging plugin back on) - I assume, this includes the mentioned commit
Comment 20 Justin Zobel 2020-12-09 01:26:54 UTC
As there were a few people that reported this I'll leave it open for a little longer for them to confirm, if they don't the bug will close itself around the 22nd of December.
Comment 21 Bug Janitor Service 2020-12-24 04:34:40 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 22 Bug Janitor Service 2021-01-08 04:34:11 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!