30

My relatively fresh Ubuntu 19.10 on a top notebook is running flawlessly, but some applications are really slow to start. For now it's keepassX, filezilla, deadbeef. Both takes about 30 seconds to show it's window, but after that both are blazing fast as others. May be someone can help me to find a solution?

Improve this question
2
  • 3
    Just found a partial answer to the question on ArchLinux forums. They are proposing that problem is related to dbus and for me starting application with dbus-launch --exit-with-session filezilla solves the problem. But I don't understand the proposed solution entirely, so I can't solve the problem. So, it's a dbus timeout that causing the delay. bbs.archlinux.org/viewtopic.php?id=230036
    – WhiteWind
    Oct 29, 2019 at 16:37
  • I had the same issue for Ubuntu 18.04 (kubuntu). The lockscreen become very slow and also the Konsole app.
    – Michael D
    Jun 28, 2021 at 19:12

7 Answers 7

Reset to default
35

After having the same problem and doing strace + a lot of reasearch I found out that this fixes the issue for good (filezilla, keepassX etc. all launch instantly now):

sudo apt-get install appmenu-gtk2-module

Then reboot.

Improve this answer
10
  • 2
    Oh!!!! You have saved me from reinstalling! It really solved the problem for me. Just need to restart and everything works as before.
    – WhiteWind
    Nov 20, 2019 at 19:08
  • 1
    Perfect. Thanks
    – Enrique Moreno Tent
    Dec 1, 2019 at 12:14
  • 2
    Working. Please specify on the reply that a reboot after package install is necessary.
    – karlacio
    Jan 15, 2020 at 17:30
  • Wow, this fixed reduced Files opening time on 19.10 from 30+ seconds to < 1 second, thank you!!
    – Davem M
    Feb 14, 2020 at 22:24
  • This also fixed slow opening of TrueCrypt and Unison-gtk. Thank you!
    – maqp
    Feb 18, 2020 at 7:40
3

Cannot confirm that installing appmenu-gtk2-module solves the problem. Also the "dbus-launch --exit-with-session" only provides a partial solution. For example VLC is facing the same startup issues. Starting it as "dbus-launch --exit-with-session vlc" avoids the described startup delay. However, integration into top panel and raven is lost in Budgie desktop.

Hence the question what exactly causes this problem and how to really solve it is still open.

Edit: I would like to clarify, what I consider being not OK with VLC when executed with dbus-launch. I attached four screenshots - two being suffixed with OK which show the integration into Budgie when being executed without dbus-launch. The second set - suffixed with NOK shows it being executed with dbus-launch. The difference is particularly noticeable in the vlcRaven screenshots. Furthermore the behavior when clicking the top panel icon is different. With dbus-launch left-clicking the icon reveals the shown menu, while the same hides/shows the application. The menu is opened upon right-clicking the icon. I do not consider the different behavior as showstopper for me though it might provide additional hints what's actually causing the issue.

VLC Raven panel NOK VLC Raven panel OK Top panel NOK Top panel OK

Improve this answer
2

I can confirm the issue. For some application the launch is heavy delayed, other applications are starting pretty fast. After the launch every application is running normal without any further delays.

I am also able to confirm that I dont have any issues with starting applications if I'm using dbus-launch --exit-with-session vlc. Also running the application as root removes the delay.

strace is stopping at that point with all delayed applications:

poll([{fd=14, events=POLLIN}], 1, 25000) = 1 ([{fd=14, revents=POLLIN}])
read(14, "\1\0\0\0\0\0\0\0", 16)        = 8
poll([{fd=14, events=POLLIN}], 1, 25000

I'm happy for any hint!

Edit: If somebody is looking for a temporary solution for budgie:

  1. Install menulibre

  2. Open Menu Editor (menulibre) and search for the application which is delayed in startup

  3. Add dbus-launch --exit-with-session APPLICATION to the launching command

  4. Unpin it from Icon Task list

  5. Open app through menu and pin it again

Now the application will start with the dbus-launch command from the start menu and taskbar.

Improve this answer
1
  • I found, that you always make a copy of dbus-launch for each application and for each instance you start that way. So, it's a very-very temporary solution, as is you are on a rarely restarting system (like my notebook) it would not be a good deal to feed all RAM to the dbus-launch remnants.
    – WhiteWind
    Nov 17, 2019 at 20:44
2

I found a possible solution to what seems to be the same problem, which only seems to affect QT (as opposed to GTK) apps and only manifested after a clean Ubuntu Budgie 19.10 install (but not on an in-place upgrade):

  • Edit the ~/.profile file in your /home/$(whoami) director
  • Near the top, add: export QT_STYLE_OVERRIDE=cleanlooks (instead of 'cleanlooks', you may also be able to use one of cde, motif, plastique, Windows or Fusion (but not 'gtk2', which implies it is some dependency problem or other) - the Arch wiki has more information on this environment variable.
  • Log out and log in again, and the QT apps should start super fast again.

You do lose the gtk2 theming of QT apps, though in VLC you can manually set it to use gtk2 theming and it seems to work fine.

Manually setting dbus-launch with QT apps also worked for me (although it leaves orphaned dbus-daemon processes running after each app closes).

Improve this answer
1
  • This fixes the issue for me for some Qt programs. I was getting a long delay for every startup. This is on Linux Mint 20.3 MATE.
    – Gavin Smith
    Sep 10, 2022 at 13:27
2

I had a similar problem with GTK-applications and xmonad (and starting X via xinit). I solved it by adding the following line to my .xinitrc:

dbus-update-activation-environment DISPLAY XAUTHORITY
Improve this answer
2
  • Thanks, the above worked for me on Arch linux.
    – Miguel Mota
    Jun 30, 2020 at 21:43
  • At first, the appmenu-gtk2-module package worked for me. Then I reinstalled the OS, upgraded to testing, and the appmenu-gtk2-module no longer solved the problem, but dbus-update-activation-environment DISPLAY XAUTHORITY did! I now employ both the solutions and evince and pavucontrol both start up blinding fast where they used to consume many minutes. Other applications that were "reasonable" are starting up much faster. Man says "If VAR is present in the environment of dbus-update-activation-environment, set it to the same value for D-Bus services." I would have never figured it out. Thanks.
    – Paul
    Jun 6, 2022 at 23:19
0

I too ran into this problem when upgrading to 20.04. After much reading and testing, I found you receive Two different versions of 20.04 depending on which Upgrade route you choose. If you choose the Internet Release-Upgrade method with 18.04.4 you Don't have this problem, all Apps open instantly when run as Root or User. If you use the Clean install method with the downloaded image, then you have this problem where Apps open instantly when run as Root but experience a DBUS timeout when run as User.

So it would seem Ubuntu will install two different systems, which one is the intended version? For me, I much prefer the Release-Upgrade method as I find it troubling to have a system that works when running Apps as Root but doesn't when run as User.

Regards, Tom

Improve this answer
0

As mentioned here dbus-launch --exit-with-session APPLICATION leaves orphaned dbus-daemon processes running after each app closes. So i wrote a little script to avoid it:

#!/bin/bash

app="$1"
shift

dbus-launch --exit-with-session "$app" "$@" & pid=$!; sleep 0.5 && export killme=$(pgrep -nx dbus-daemon); export killme2=$(pgrep -f "dbus-launch --exit-with-session $app"); wait $pid && kill $killme $killme2

Save it to your bin PATH, e.g. in ~/bin directory, named fastrun, and run it like:

fastrun APPLICATION
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.