No results from application scope until Unity is restarted
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Unity |
Confirmed
|
Undecided
|
Unassigned | |
| | unity (Ubuntu) |
Medium
|
Unassigned | ||
| | Xenial |
Medium
|
Unassigned | ||
Bug Description
Unity is in a state where I don't get any results from the applications lens. This sometimes happens for one search but either re-entering the search or toggling the lens has always fixed it in the past for me. This time neither of these steps work.
I'm attaching a bustle log of the problem in case that's helpful. I searched for "spotify", which I've got installed, and got 0 results.
The only way to fix the issue is to log out and back in.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unity 7.2.0+14.
ProcVersionSign
Uname: Linux 3.13.0-23-generic x86_64
ApportVersion: 2.14.1-0ubuntu2
Architecture: amd64
CompizPlugins: No value set for `/apps/
CurrentDesktop: Unity
Date: Tue Apr 15 13:29:40 2014
InstallationDate: Installed on 2012-10-07 (554 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121007)
SourcePackage: unity
UpgradeStatus: Upgraded to trusty on 2013-05-07 (343 days ago)
| Iain Lane (laney) wrote : | #1 |
| tomdryer (tomdryer-com) wrote : | #2 |
| Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in unity (Ubuntu): | |
| status: | New → Confirmed |
| Michal Hruby (mhr3) wrote : | #4 |
Unfortunately the bustle log just shows that the home scope doesn't query the applications scope, but it's not known why. It would be useful if bustle was run earlier, so the initial query (and reason it presumably? failed) to the applications scope would be visible.
| Changed in libunity: | |
| status: | New → Confirmed |
| summary: |
- No results from application lens + No results from application scope |
| description: | updated |
Earlier as in when?
If you mean before the very first query, I don't know when the problem's going to happen (have no reproduction recipe), so unless I just run it at every session startup we're not going to catch this state.
| Paweł Stołowski (stolowski) wrote : | #6 |
If I got that right, when it happens, you don't get results from applications in Home and also from Application lens (Super+A)?
| Iain Lane (laney) wrote : | #7 |
I didn't try the lens explicitly, but I can do the next time it happens.
I made sure the right filters were selected in Home, and tried toggling them a lot.
| Paweł Stołowski (stolowski) wrote : | #8 |
@Iain, if it happens again, can you also please collect the output of:
gsettings get com.canonical.
gsettings get com.canonical.
gsettings get com.canonical.
(run them in the terminal).
| Michal Hruby (mhr3) wrote : | #9 |
@pstolowski, from the bustle log it's visible that there's a query to .../masterscope
| Paweł Stołowski (stolowski) wrote : | #10 |
I've just experienced this issue after starting the session. There is no process running for unity-scope-
| Paweł Stołowski (stolowski) wrote : | #11 |
| CSRedRat (csredrat) wrote : | #12 |
When this fixed in 14.04 Trusty Tahr for 14.04.1 (24 July)?
I have this problem once in a while. I can never be sure if the Dash will work and display results for applications and sometimes also files.
Today I had to relog two times to get results in Dash home for applications and the applications lens also didn't work and even the run command lens (Alt+F2).
It happened again today. I don't get any results for applications in Home and Applications lens but this time the commands scope (Alt+F2) works.
Output of gsettings get:
$ gsettings get com.canonical.
['music.scope', 'music-
$ gsettings get com.canonical.
['applications.
$ gsettings get com.canonical.
['more_
Another day and another failure of applications scope. This time I had to relog three times to get applications in Dash.
I captured bustle.log which should be useful because it runned right from the start of system. I used the script written by Ted Gould.
| Michal Hruby (mhr3) wrote : | #16 |
@Mateusz: Your dbus log is pretty much the same as Pawel's, it says that activation of the application scope timed out, but doesn't provide any indication why.
The bustle log captured only the first 30 seconds of the startup process (as the upstart script tells it to), and in that time scopes didn't even begin starting up.
You could try bumping the timeout to 90 seconds, and that might provide more data, but I'm afraid it still won't point to why is the apps scope startup taking that long.
Another try this time I bumped the timeout just like you advised.
However instead of 90 seconds I set it to 120 seconds. I hope it isn't overkill.
| Michal Hruby (mhr3) wrote : | #18 |
So from looking at the log:
23.19s - Unity queries applications masterscope
26.37s - apps scope appears on bus
43.49s - BAMF query for running apps
43.58s - Search invoked on apps scope
48.20s - Search inside apps masterscope timed out, sent no-results reply
52.30s - Search in apps scope finishes
So on your machine it took the apps scope ~20 seconds to initialize and start processing requests, and then another ~9 seconds to process the first request, which is pretty bad, cause the dbus timeout is 25seconds. Although from the log it's also visible that the apps scope did respond to further searches, I assume the case where it doesn't work at all is when the initial initialization itself takes more than 25 seconds.
All in all, I'd attribute bad IO performance to this issue, but clearly the apps scope should handle that better.
| Changed in unity-lens-applications: | |
| status: | New → Confirmed |
| Yanpas (yanpaso) wrote : | #19 |
That how my app scope looks sometimes. Only relogining helps. Is that bug similar or I need to create new? And is there a way to get this scope work without relogin?
That's this bug. Mark it as affecting you.
You could reload Unity with this command:
unity &> /dev/null & disown
But it may result in some 3rd party indicators not showing up after the reload. Note that all the default indicators will work.
| Changed in unity: | |
| status: | New → Confirmed |
| Changed in unity (Ubuntu): | |
| importance: | Undecided → Medium |
| Guillaume F (marsguo) wrote : | #21 |
It happens on my system too, with 14.10.
I guess it's a timeout problem, because it usually happens when I'm too eager to open the Dash right after a cold boot (those can be very long). The files scope is quite long to come up too, but at least it comes up.
| Allard Pruim (allardpruim) wrote : | #22 |
This bug was introduced with Ubuntu 13.10 and now it is still not fixed.
| Allard Pruim (allardpruim) wrote : | #23 |
Update: For some reason this bug affects me when I install Google Chrome, when I remove it this bug strangely doesn't appear.
This got for me to the point that I always don't get any results in Dash Home after opening it. Fortunately there is a workaround in my case. If I open the applications lens directly with shortcut (Super + A) or with quicklist it gets results and then the Dash Home starts working.
I'm now on fully updated Vivid which was upgraded directly from Trusty (sudo sed -i 's/trusty/vivid/g' /etc/apt/
| fernando biondi (fbiondip) wrote : | #25 |
This bug affects Unity when browsing youtube videos using Chrome or Chromium
Looks like I solved the problem on my machine thanks to a recent post in Ubuntu subreddit.
The post was titled: How I sped up my Ubuntu Dash. The user had problems with Dash being very slow to show him search results and he found out that the culprit was Zeitgeist. This thing tracks the files, applications you used and your other activities.
It turned out that his Zeitgeist history was over two years long! When I checked on my system I had it dating back to February 2012 so it was even longer than his.
I deleted the folder /home/your_
http://
| tags: | added: rls-w-incoming |
| Changed in libunity (Ubuntu): | |
| status: | New → Confirmed |
| Alex Baggott (alex-baggott) wrote : | #27 |
Thank you for taking the time to report this bug. We have tried to recreate this on the latest release of Ubuntu and cannot reproduce it. This bug is being marked as Invalid. If you believe the problem to still exist in the latest version of Ubuntu, please comment on why that is the case and change the bug status to NEW.
| Changed in unity: | |
| status: | Confirmed → Invalid |
| Changed in libunity: | |
| status: | Confirmed → Invalid |
| Changed in unity-lens-applications: | |
| status: | Confirmed → Invalid |
| Changed in libunity (Ubuntu): | |
| status: | Confirmed → Invalid |
| Changed in unity (Ubuntu): | |
| status: | Confirmed → Invalid |
| Will Cooke (willcooke) wrote : | #28 |
Laney still has this problem. Reopening and adding "desktop-
| tags: | added: desktop-bugscrub-reopened |
| Changed in unity: | |
| status: | Invalid → Confirmed |
| Changed in unity (Ubuntu): | |
| status: | Invalid → Confirmed |
| tags: | added: desktop-bugscrub-triaged |
| Iain Lane (laney) wrote : | #29 |
I'm unduping this - bug #1295908 says that there are two ways to fix (try again or check 'applications' in the filters list). This bug is about being in a state where neither of these cases work - apps are never returned until unity is restarted.
I got it once again a couple of weeks ago but I forgot to try that apps lens (comment #6), sorry - will try to remember next time.
| summary: |
- No results from application scope + No results from application scope until Unity is restarted |
| no longer affects: | libunity (Ubuntu) |
| affects: | libunity → ubuntu |
| no longer affects: | ubuntu |
| affects: | unity-lens-applications → ubuntu |
| no longer affects: | ubuntu |
| tags: |
added: rls-x-incoming removed: rls-w-incoming |
| Rodrigo (rodhos-hp) wrote : | #30 |
This happened to me on Vivid but I can't reproduce this problem on Wily. Also, searches seems to be a lot faster.
| tags: | removed: rls-x-incoming |
| Ben Romer (bromer) wrote : | #31 |
This is happening to me on 15.10 right now. :(


Duplicate of bug #1295908?