No results from application scope until Unity is restarted

Duplicate of bug #1295908?

Status changed to 'Confirmed' because the bug affects multiple users.

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.

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.

If I got that right, when it happens, you don't get results from applications in Home and also from Application lens (Super+A)?

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.

@Iain, if it happens again, can you also please collect the output of:

gsettings get com.canonical.Unity.Lenses home-lens-default-view
gsettings get com.canonical.Unity.Lenses always-search
gsettings get com.canonical.Unity.Lenses disabled-scopes

(run them in the terminal).

@pstolowski, from the bustle log it's visible that there's a query to .../masterscope/applications with subscope_filter=['applications-applications.scope', 'applications-scopes.scope'], so not filter related.

I've just experienced this issue after starting the session. There is no process running for unity-scope-applications. ~/.cache/upstart/dbus.log and gnome-session-Unity.log file indicate a problem with connecting to apps / commands scope. Attaching both logs.

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.Unity.Lenses home-lens-default-view
['music.scope', 'music-audacious.scope', 'music-gmusicbrowser.scope', 'music-grooveshark.scope', 'music-musicstore.scope', 'music-rhythmbox.scope', 'music-songsterr.scope', 'music-soundcloud.scope', 'files.scope', 'files-gdrive.scope', 'files-local.scope', 'applications.scope', 'applications-applications.scope', 'applications-scopes.scope']

$ gsettings get com.canonical.Unity.Lenses always-search
['applications.scope', 'music.scope', 'videos.scope', 'files.scope']

$ gsettings get com.canonical.Unity.Lenses disabled-scopes
['more_suggestions-skimlinks.scope', 'more_suggestions-ebay.scope', 'photos-facebook.scope', 'music-audacious.scope', 'more_suggestions-amazon.scope']

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.

http://gould.cx/ted/blog/Bustle_Boot_Log_Under_Upstart

@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.

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.

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.

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.

This bug was introduced with Ubuntu 13.10 and now it is still not fixed.

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/sources.list).

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_user_name/.local/share/zeitgeist (almost 700 MB of data) containing the Zeitgeist history just like he did and I confirm that it sped up Dash. But it also resolved the problem described in this bug report.

http://www.reddit.com/r/Ubuntu/comments/2ysuqu/how_i_sped_up_my_ubuntu_dash/

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.

Laney still has this problem. Reopening and adding "desktop-bugscrub-reopened" tag so that it won't get auto-closed in the future.

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.

This happened to me on Vivid but I can't reproduce this problem on Wily. Also, searches seems to be a lot faster.

This is happening to me on 15.10 right now. :(

Actual for Xenial