xfce4-appfinder launches very slowly

[morlock]

Steps to reproduce: run xfrun4 or xfce4-appfinder

What I expect to happen: the programs should launch almost immediately
What happens instead: it takes several seconds for them to launch.

When I run one of the commands from inside a terminal I get the following error message:

(xfrun4:2882): xfce4-appfinder-CRITICAL **: Failed to open window: 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.

Ubuntu version + package version:

$ lsb_release -d
Description: Ubuntu quantal (development branch)

$ apt-cache policy xfce4-appfinder
xfce4-appfinder:
  Installed: 4.10.0-1
  Candidate: 4.10.0-1
  Version table:
 *** 4.10.0-1 0
        500 http://de.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages
        100 /var/lib/dpkg/status

[Launchpad Janitor (janitor)]

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

[Nikolay Mitev (theface)]

launching with --disable-server makes both apps appear instantly without errors.

[Misha Bazanov (bmw-)]

Nikolay, thanks for workaround.

[Graeme Donaldson (thatgraemeguy)]

Nokolai's workaround works, does anyone know what the impact is of adding --disable-server though? The help text says "Do not try to use or become a D-Bus service", but what are the implications (if any) for those of us who may not fully understand what D-Bus services are?

[Balaji G (balajig81)]

I face exactly the same problem and the work around works fine absolutely.

Thanks,

[Erik S (ofenfisch)]

This problem affect me since a few days. The Appfinder suddenly needed like 5-10 seconds to launch. It worked fine the days before. (I set up my Xubuntu completly new 2 weeks ago). Workaround works fine :)

Maybe this has something to do with the option "Keep running instance in the background" in the settings-window of the appfinder? Any ideas?

[Peter Jenkins (peterjenkins)]

Workaround works. :-)

For me this problem started when I updated Ubuntu 12.04 to 12.10. I was already using xfce 4.10 from the semi-official PPA, so I'm guessing something broke during the update.

[miccs (meomic)]

i do not want to spam but maybe it will help to find what causes that bug...

i have the same exact situation as mr. Peter Jenkins (comment above)

i was using 4.10(ubuntu 12.04) from this ppa: http://ppa.launchpad.net/xubuntu-dev/xfce-4.10/ubuntu
and it worked well - neved used quantal betas so cant tell if it was working there...

[Stéphane Gourichon (stephane-gourichon-lpad)]

Bug confirmed on new install of Ubuntu 12.10 Quantal.

Creating a new user, logging with XFCE session, selecting "default settings" (instead of "empty panel"), the bug can be reproduced (either using Alt-F2 or running xfrun4 from terminal).

[Jochen Kemnade (jochenkemnade)]

Still an issue in raring, the workaround also still works.

[Snild (snild)]

Very strange -- this problem suddenly appeared on my laptop today (Xubuntu 13.04, appfinder version 4.10.0-1ubuntu1). The workaround mentioned above helped. But workarounds tend to leave a bad aftertaste...

Looked into it. It's a dbus call that times out (5 second timeout, but in newer code it's "only" 2 secs). More specifically, it's the "OpenWindow" dbus call, meant to be handled by the running appfinder server -- ironically intended to speed up launches by avoiding repeated initializations.

I've attached part of an strace around where the problem occurs. Timestamps and duration are printed for each call (before and after the call info, respectively).

I also noticed that dbus seemed to think that "org.xfce.Appfinder" was owned by someone, even though I couldn't find any living appfinder processes. I'm not familiar with dbus, but instinctively, I'd assume that's a bad thing.

Killing the dbus-daemon made the problem go away -- of course, that also killed my whole desktop session, and I'm not sure which thing helped. Regrettably, I don't know how to trigger the problem again.

Some commands that might be useful...

Check which name owns "org.xfce.Appfinder":
$ dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.xfce.Appfinder

..and check which PID has that name (replace the last arg with your appfinder's name):
$ dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID string::1.66
(yes, that's a double colon -- one to separate the type and name, and one is actually part of the name.)

That process has probably died, though, and only its fork will be left. For example, (after I'd restarted dbus) I got 4038 from the command above, and had a daemonized appfinder at 4039:
$ ps --ppid 1 | grep appf
 4039 ? 00:00:01 xfce4-appfinder

...which, just to be clear, works fine. The exact pid isn't important, as long as someone is actually handling the bus messages.

Would be interesting to find the root cause for this. Not sure if it's in dbus or appfinder.

BTW, I think I may have had a defunct instance of appfinder when the problem occurred, but I can't remember clearly (4 a.m. is really way too late to be debugging things like this ;)). Could someone check "ps -ef | grep appf" the next time they encounter the problem?

[Snild (snild)]

It happened again.

The last note in my previous comment was wrong; there _is_ an appfinder instance running:
$ ps -Tg 4030
  PID SPID TTY TIME CMD
 4030 4030 ? 00:00:00 xfce4-appfinder
 4030 4031 ? 00:00:00 gdbus
 4030 4032 ? 00:00:00 xfce4-appfinder

Like before, DBus has another PID (4029) for the owner of "org.xfce.Appfinder", which is probably the case because of daemonization.

Attached to it with gdb.

(gdb) info threads
  Id Target Id Frame
  3 Thread 0x7faf4897d700 (LWP 4031) "gdbus" 0x00007faf5c8c83cd in poll ()
   from /lib/x86_64-linux-gnu/libc.so.6
  2 Thread 0x7faf43fff700 (LWP 4032) "xfce4-appfinder" 0x00007faf5cbb182c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
* 1 Thread 0x7faf5f0189c0 (LWP 4030) "xfce4-appfinder" 0x00007faf5cbb182c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0

Two "normal" threads, and one gdbus thread. The two first threads are waiting on a lock (or a condition?). The gdbus thread, which is currently polling for an event, would have to be the one to awaken at least one of these threads. That's reasonable -- no reason to do stuff until an event comes in.

I set a breakpoint on the next instruction in poll (after the syscall returns). It appears it doesn't recieve any events; starting another appfinder instance doesn't cause any breaks in the gdb-attached process. Hm. Looks like I may have to learn some DBus. :)

Installed d-feet, tried to look at the org.xfce.Appfinder bus. It shows nothing for a while, then pops up an error message saying "org.xfce.Appfinder : Timeout was reached". I guess that rules out any problem in the "client" code (well, maybe it could be made more robust by trying to check for this condition first, but it shouldn't be needed).

At this point, I wasn't sure what to do next, so I figured I'd kill the running appfinder daemon and see what happens.

Well, the next start was fine. It daemonized successfully, too. And all following starts worked fine as well. So at least the problem isn't persistent in the dbus-daemon. It could still be a dbus problem, of course, but it seems unlikely. So, what causes the appfinder service to stop responding? I still have no idea.

[qji (qji)]

It's the same for me, 5 seconds hang up, before the window appears. I use xfrun4 instead of xfce4-appfinder, but the result is very similar (Ubuntu 12.04, XFCE 4.8.0.3), strace attached.

--disable-server option didn't work (no this option for xfrun4?), but I killed the already running xfrun4 (xfrun4 --daemon) and it helped.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

No more hang ups after compiling the latest version of xfce4-appfinder from git. I assume that the migration to GDBus resolved this issue:

http://git.xfce.org/xfce/xfce4-appfinder/commit/?id=4a065a10945c72c985e254ff1ef13df188f3e11e

Xubuntu 13.10 Beta 2

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

The delay seems to be caused by the overlay-scrollbar module. Deactivating these scrollbars restores the normal launch behavior.

Simple test case:

$ killall -9 xfce4-appfinder
$ LIBOVERLAY_SCROLLBAR=0 xfce4-appfinder

[Launchpad Janitor (janitor)]

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

[Paul Annekov (paul.annekov)]

In Xubuntu 13.10 there was no lags but after update to Xubuntu 14.04 the delay appeared again :(.

[Stephen Warren (srwarren)]

Re: comment #16: In Trusty/14.04, removing overlay-scrollbar does not solve the issue. I never tested if it worked for me on earlier releases.

[badidea (very-bad-idea)]

I have these problems in both:
Xubuntu 14.04 32bit and
Ubuntu14.04 64bit with xfce

[badidea (very-bad-idea)]

Edit:

The Xubuntu 14.04 32bit is a netbook upgraded from Xubuntu 13.10
The Ubuntu14.04 64bit with xfce is a PC (intel core2duo / nvidia graphics) clean install

Seems like a problem with dbus. Multiple applications and tasks produce dbus error or react slow:
- xfce4-appfinder
- gedit
- modemmanager
- logging off
- keyboard shortcuts?

[badidea (very-bad-idea)]

edit: Probable not gedit.

If I remove overlay-scrollbar packages I get, on first try:

$ xfce4-appfinder
Gtk-Message: Failed to load module "overlay-scrollbar"

Then nothing happens, and on second try:

$ xfce4-appfinder
Gtk-Message: Failed to load module "overlay-scrollbar"

(xfce4-appfinder:2770): xfce4-appfinder-CRITICAL **: Failed to open window: 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.

And then form 'ps x':
 2769 ? Ss 0:00 xfce4-appfinder
 2790 pts/17 Sl+ 0:00 xfce4-appfinder

[badidea (very-bad-idea)]

edit: 2790 should have been 2770

[badidea (very-bad-idea)]

Update on 14.04:

Reproducible in virtualbox as well
* virtualbox 4.3.10
* install ubuntu 64bit (or 32bit) desktop iso
* install the virtualbox client side stuff for higher then 640x480 resolution
* disable zeigeist stuff in privacy options
* disable amazon stuff in privacy options (not important for this bug, but obvious action)
* (sudo apt-get update & upgrade)
* sudo aptget install xfce4
* reboot
* login to xfce
* terminal: xfce4-appfinder --> bug

* enable zeigeist stuff in privacy options
* reboot
* login to xfce
* terminal: xfce4-appfinder --> NO bug

To bested on my other systems

[badidea (very-bad-idea)]

Note: privacy stuff available under xfce via unity-control-center (ignore the errors and missing icons)

[badidea (very-bad-idea)]

It seems it was wrong, I cannot reprocude the relation with zeitgeist.

Since 3 out of 3 my xfce installations on ubuntu have this problem and other dbus problems, but at the same time no one else seems to have these problems, I guess have to find an alternative distro to get xfce propperly working.

[badidea (very-bad-idea)]

I did a clean install of Xubuntu 14.04 64-bit on one of the systems and after several reboots and installing most my typical software packages, the dbus issues have not appeared.

If this remains the case for several days, I will do a clean install on the other system as well.

For anyone ending up here with these issues, I say: Good luck!

[Paul Annekov (paul.annekov)]

Xubuntu 14.04 (updated from 13.10). After update application finder has become to start with great delay.
I have added --disable-server parameter to shortcut and problem was solved.

[Luke Schlather (luke2760)]

Should we open a separate bug for xfrun4? I'm getting issues with it right now, but xfce4-appfinder is snappy.

[David Fraser (davidf)]

Added this to my ~/bin directory (on my path) as xfce4-appfinder and symlinked xfrun4 to it:

#!/bin/bash
extra_params=""
[ "`basename "$0"`" == "xfrun4" ] && { extra_params="-c" ; }
exec /usr/bin/xfce4-appfinder --disable-server $extra_params "$@"

[Stefano Tarquini (esteban-turquoise)]

I have Xubuntu 12.04 LTS (32 bit) and only xfce4-appfinder starts with a great delay (almost 4-5 sec).
xfrun4 (Alt+F2) starts fast instead.
I have also Xubuntu 14.04 LTS (32 bit) on the same netbook and when i start xfce4-appfinder it is fast, no delay.
The option "--disable-server" is unknown for the command xfce4-appfinder.

[Martin Spacek (mspacek)]

I have this issue for both xfce4-appfinder and xfrun4 on a fresh install of Xubuntu 14.04 amd64 on a Thinkpad W510 with nvidia binaries. Running them with --disable-server makes start times instantaneous. Otherwise, there's an unbearable 10-20 sec delay, and sometimes multiple zombie instances running simultaneously.

Bug #1314782 (multimedia keys don't work when xfce4-volumed is run in daemon mode) might be the ultimate fix for all of this, assuming that patch can be applied to more than just xfce4-volumed. Seems like it's some kind of race condition, or forking of processes in the wrong order. Something like that.

[Alberto Salvia Novella (es20490446e)]

Steps to reproduce: run xfrun4 or xfce4-appfinder

What I expect to happen: the programs should launch almost immediately
What happens instead: it takes several seconds for them to launch.

When I run one of the commands from inside a terminal I get the following error message:

(xfrun4:2882): xfce4-appfinder-CRITICAL **: Failed to open window: 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.

Ubuntu version + package version:

$ lsb_release -d
Description: Ubuntu quantal (development branch)

$ apt-cache policy xfce4-appfinder
xfce4-appfinder:
  Installed: 4.10.0-1
  Candidate: 4.10.0-1
  Version table:
 *** 4.10.0-1 0
        500 http://de.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages
        100 /var/lib/dpkg/status

[Alberto Salvia Novella (es20490446e)]

It's a usability issue that doesn't limit the functionality of a core package.

[Martin Spacek (mspacek)]

On the advice of AlbertoSalvia Novella , I've submitted a new bug report against dbus with links to all the bugs (in my install of Xubuntu 14.04) that I vaguely suspect are related to one another:

Bug #1347272 (DBus communication problems affecting multiple packages)