xfce4-appfinder launches very slowly

Reported by morlock on 2012-09-10
This bug affects 42 people
Affects Status Importance Assigned to Milestone
xfce4-appfinder (Ubuntu)
xfce4-utils (Ubuntu)

Bug Description

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
  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) wrote :

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

Changed in xfce4-appfinder (Ubuntu):
status: New → Confirmed
Nikolay Mitev (theface) wrote :

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

Misha Bazanov (bmw-) wrote :

Nikolay, thanks for workaround.

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) wrote :

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


Erik S (ofenfisch) wrote :

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) wrote :

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.

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

Donatas (donce-lt) on 2012-12-11
Changed in xfce4-appfinder (Ubuntu):
status: Confirmed → In Progress
status: In Progress → Confirmed
gouri (stephane-gourichon-lpad) wrote :

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) wrote :

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

Snild (snild) wrote :

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) wrote :

It happened again.

The last note in my previous comment was wrong; there _is_ an appfinder instance running:
$ ps -Tg 4030
 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) wrote :

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

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


Xubuntu 13.10 Beta 2

summary: - xfrun4 launches very slowly
+ xfce4-appfinder launches very slowly

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) wrote :

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

Changed in xfce4-utils (Ubuntu):
status: New → Confirmed
Changed in xfce4-utils (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers