[SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

aardwolf · 2023-09-04 17:52:14

Hi,

Various programs take 20+ seconds to load for me, including Archive Manager (compressed file handler plugin in Nemo file manager) and Firefox (there are more, I've also seen it happening to an epub or PDF reader for example).

My desktop is:
X-Cinnamon

My OS is:
Linux 6.4.11-arch2-1 x86_64 GNU/Linux

I found some posts here that have similar problems, but they don't solve my problem (I tried installing/uninstalling various packages like flatpack (which I don't use btw), and no difference, and, I have not been messing with systemd-resolved like someone in the other threads has):
https://bbs.archlinux.org/viewtopic.php?id=267427
https://bbs.archlinux.org/viewtopic.php?id=280162

This has been going on for a few months already and I have this happening on two different archlinux computers (a desktop and a laptop), both use Cinnamon but other than having that in common they're completely independent, if I've messed up something on one, I wouldn't have also messed it up to the other, so it has to be a common problem, not some weird edge case I hit on...

Is this a Cinnamon problem? How can I find out what's causing the slowness for me, and especially, fix it?

Thanks!

Last edited by aardwolf (2023-09-09 14:24:49)

seth · 2023-09-04 18:36:50

Wild guess, still the xdg-desktop-portal-gnome issue?

pacman -Qs portal

Otherwise please post the output of

loginctl session-status
echo $DBUS_SESSION_BUS_ADDRESS

and tail the system journal to see whether there's some messages for attempts to start FF.

yochananmarqos · 2023-09-04 19:07:06

seth wrote:

Wild guess, still the xdg-desktop-portal-gnome issue?

Good guess, however, it was fixed upstream with 44.2. I know that for a fact because I noticed the difference using more than one desktop session with more than one desktop portal installed.

RyanOrigins · 2023-09-04 19:21:52

I've also been experiencing a consistent issue with D-Bus. Whenever I start a window manager, whether it's X11 or Wayland (such as I3, DWM, BSPWM, or HYPERLAND), I notice that launching applications takes an unreasonably long time. To address this problem, I initially employed a workaround by configuring the initialization to use dbus-launch --exit-with-session (window-manager). This did alleviate the issue, but unfortunately, it caused several of my applications to stop working altogether.

Following this, I attempted an alternative approach: launching D-Bus without the --exit-with-session flag, simply using dbus-launch. While this approach did not slow down application launches as much as not starting D-Bus at all, it still resulted in slower performance.

It's worth noting that I did not encounter this problem on Debian-based distributions, suggesting that the issue may be specific to the D-Bus package on Arch Linux.

Please if anyone finds a solution let me know.

RyanOrigins · 2023-09-04 19:24:27

xdg-desktop-portal-gnome OUTPUT:

local/libportal 0.6-1
    GIO-style async APIs for most Flatpak portals
local/libportal-gtk3 0.6-1
    GIO-style async APIs for most Flatpak portals - GTK 3 backend
local/libportal-gtk4 0.6-1
    GIO-style async APIs for most Flatpak portals - GTK 4 backend
local/xdg-desktop-portal 1.16.0-3
    Desktop integration portals for sandboxed apps
local/xdg-desktop-portal-gnome 44.2-1 (gnome)
    A backend implementation for xdg-desktop-portal for the GNOME desktop environment
local/xdg-desktop-portal-gtk 1.14.1-1
    A backend implementation for xdg-desktop-portal using GTK

Last edited by RyanOrigins (2023-09-04 19:46:18)

seth · 2023-09-04 19:27:27

If dbus-launch "helped" you, you're most likely just not importing the session environment (for X11 a broken xinitrc is the usual cause, last link below)
But in general this could be anything, start w/ the output for the commands in #2 and please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Edit: unless you're using flatpak, get rid of all xdg-portal* packages
Otherwise at least remove xdg-desktop-portal-gnome and if the problem remains, see above.

Last edited by seth (2023-09-04 19:29:51)

RyanOrigins · 2023-09-04 19:37:29

First

           Since: Mon 2023-09-04 16:30:08 -03; 1min 56s ago
          Leader: 191376 (gdm-session-wor)
            Seat: seat0; vc2
             TTY: tty2
         Service: gdm-password; type wayland; class user
           State: active
            Idle: no
            Unit: session-14.scope
                  ├─191376 "gdm-session-worker [pam/gdm-password]"
                  ├─191846 /usr/lib/gdm-wayland-session --register-session Hyprland
                  ├─191853 Hyprland
                  ├─192035 /bin/sh -c "WAYLAND_DISPLAY=wayland-1 DISPLAY=:0 hyprpaper & waybar"
                  ├─192038 waybar
                  ├─192128 /usr/lib/firefox/firefox
                  ├─192243 alacritty
                  ├─192268 /bin/bash
                  ├─192315 /usr/lib/firefox/firefox -contentproc -parentBuildID 20230828231221 -prefsLen 26670 -prefMapSize 232451 -appDir /usr/lib/firefox/browser {d4f1f102-c64f-496b-9>
                  ├─192332 /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 26811 -prefMapSize 232451 -jsInitLen 235824 -parentBuildID 20230828231221 -appDir /us>
                  ├─192384 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 32384 -prefMapSize 232451 -jsInitLen 235824 -parentBuildID 20230828231221 -appDir /us>
                  ├─192427 /usr/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 29584 -prefMapSize 232451 -jsInitLen 235824 -parentBuildID 20230828231221 -appDir /us>
                  ├─192430 /usr/lib/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 29584 -prefMapSize 232451 -jsInitLen 235824 -parentBuildID 20230828231221 -appDir /us>
                  ├─192434 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 29584 -prefMapSize 232451 -jsInitLen 235824 -parentBuildID 20230828231221 -appDir /us>
                  ├─192502 /usr/lib/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 29584 -prefMapSize 232451 -jsInitLen 235824 -parentBuildID 20230828231221 -appDir /us>
                  ├─192599 loginctl session-status
                  └─192600 less

 9月 04 16:30:35 arch /usr/lib/gdm-wayland-session[192038]: [2023-09-04 16:30:35.489] [warning] module sway/mode: Disabling module "sway/mode", Socket path is empty
 9月 04 16:30:35 arch /usr/lib/gdm-wayland-session[192038]: [2023-09-04 16:30:35.494] [warning] module sway/scratchpad: Disabling module "sway/scratchpad", Socket path is empty
 9月 04 16:30:35 arch /usr/lib/gdm-wayland-session[192038]: [2023-09-04 16:30:35.494] [warning] module wlr/window: Unknown module: wlr/window
 9月 04 16:30:35 arch /usr/lib/gdm-wayland-session[192038]: [2023-09-04 16:30:35.497] [warning] module wlr/language: Unknown module: wlr/language
 9月 04 16:31:15 arch /usr/lib/gdm-wayland-session[192559]: 00:01:06.146 [INFO] [xwayland/server.c:108] Starting Xwayland on :0
 9月 04 16:31:15 arch /usr/lib/gdm-wayland-session[192571]: The XKEYBOARD keymap compiler (xkbcomp) reports:
 9月 04 16:31:15 arch /usr/lib/gdm-wayland-session[192571]: > Warning:          Unsupported maximum keycode 708, clipping.
 9月 04 16:31:15 arch /usr/lib/gdm-wayland-session[192571]: >                   X11 cannot support keycodes above 255.
 9月 04 16:31:15 arch /usr/lib/gdm-wayland-session[192571]: Errors from xkbcomp are not fatal to the X server
 9月 04 16:32:03 arch /usr/lib/gdm-wayland-session[191853]: 00:01:53.831 [INFO] [xwayland/server.c:215] Restarting Xwayland (lazy)

sudo journalctl -b | curl -F 'file=@-' 0x0.st

I cannot execute it hangs my terminal.

I'm not using xinitrc, there is nothing written in it.

Last edited by RyanOrigins (2023-09-04 19:45:55)

seth · 2023-09-04 19:42:26

Please use [code][/code] tags. Edit your post in this regard.

sudo journalctl -b > /tmp/journal.txt
du -hs /tmp/journal.txt
cat /tmp/journal.txt | curl -F 'file=@-' 0x0.st

Is that native or xwayland firefox and does that impact the start performance?
https://wiki.archlinux.org/title/Firefox#Wayland

How did you "dbus-launch --exit-with-session" when using GDM??

RyanOrigins · 2023-09-04 19:44:57

Removing xdg-desktop-portal-gnome fixed the problem.

Thank you

sudo nvim /usr/share/wayland-session/(window-manager.desktop) - Edit the Exec: and add the line.

yochananmarqos · 2023-09-04 22:49:31

seth wrote:

unless you're using flatpak, get rid of all xdg-portal* packages

What??? There's more to it than just Flatpak. I don't know what DE or WM you use, but if one keeps things very simple maybe it is possible not to have one installed. However, the OP is using Cinnamon which now pulls in the new xdg-desktop-portal-xapp dependency. He cannot remove it. However, he removed xdg-desktop-portal-gnome which he should have done months ago, anyway.

There are XDG Desktop Portal packages in the repos for GNOME, Gtk, Cinnamon (xapp), Hyprland, KDE, LXQt and wlroots (wlr). There is also a Pantheon package in the AUR and System76 has their own Cosmic package for their upcoming DE that's still in Alpha. I have both xdg-desktop-portal-gnome and xdg-desktop-portal-cosmic installed with my GNOME and Cosmic desktop sessions using GDM. Before the xdg-desktop-portal-gnome 44.2 update, there was a long delay launching applications in my Cosmic session. I've also seen the reports mostly dry up since then.

seth · 2023-09-05 06:01:11

RyanOrigins isn't the OP, whether the OP still has xdg-desktop-portal-gnome is unknown.
Reading through the clusterfuck of the upstream bug, the "fix" might very much depend on how the environment is launched, ersp. what state it reaches and there might be a specific issue w/ Hyprland (in this case)

xdg-portal is still predominantly a flatschpak thing and if I've to choose between the UX disaster that is the gtk/gnome file dialog or the convoluted and fragile design of xdg-portal and its implementations, I'll err… "happily"? deal with the gtk file dialog.
Gnome apparently has plans to use it to determine the default terminal emulator, because I guess the pre-existing config key or just adhering to $TERMINAL would be too much straight forward.

I wasn't aware that the cinnamon package hard-depends on an, let alone a specific xdg-portal implementation, but that almost seems like a packaging bug.
In particular since we now know about the damage potental of any singular crappy xdg-desktop-portal-impl, ie. cinnamon would ideally at most rely on that so xdg-desktop-portal-xapp can, in need, be substituted by eg. xdg-desktop-portal-gtk

Let's see how the OPs situation pans out.

aardwolf · 2023-09-09 14:24:25

Sorry, only got back to this now... indeed it was the portal issue for me, and it got fixed by removing specifically these packages:

pacman -R xdg-desktop-portal-gtk
pacman -R xdg-desktop-portal-gnome

Now firefox starts up fast! And cinnamon at least still seems to work.

I hope this package won't be installed again by something, or even be required by something I want to use in the future, though.

I do hope that gnome / flatpack are aware of this issue and they care about not causing a slowdown in programs like firefox on linux installations.

seth · 2023-09-09 14:52:15

Well, https://bugs.archlinux.org/task/78735 certainly explains how cinnamon came to its, relatively new, hard dependency packaging probably-bug…

@yochananmarqos, do you want to suggest to make it pure optional¹ or create a dependency on an unspecific xdg-desktop-portal-impl rather than the specific xdg-desktop-portal-xapp?
(The cinnamon package doesn't look like it's a pure meta-package, so it's not an optional "get me all stuff cinnamon" thing)
Also the bug suggests that xdg-desktop-portal-xapp might indeed depend on xdg-desktop-portal-gtk?

¹ The only packages currently hard-depending on xdg-desktop-portal-impl are
* flatpak
* lutris (Open Gaming Platform)
* kooha (some screen recorder)
* krfb (KDE desktop sharing)
* shutter (screenshot too)
And I'll argue that for at least the latter three it's gonna be by mistake.

@aardwolf, xdg-desktop-portal-gnome draws in xdg-desktop-portal-gtk, but you'll have to check your pacman log to see in what context you installed xdg-desktop-portal-gnome

RyanOrigins · 2023-09-11 06:50:22

Hey seth, I'm running into another problem related to GNOME, every single time i open chrome on gnome and then on a window manager, all my passwords are gone and i have to re-login. (I would open another post but i didn't manage to figure out how to do that yet)

seth · 2023-09-11 10:28:04

Please open a new thread for this unrelated topic: https://bbs.archlinux.org/post.php?fid=18
The cause is probably related to the use of different password stores, https://wiki.archlinux.org/title/Chromi … word_store

RyanOrigins · 2023-09-11 15:53:32

It fixed the problem, Thank you.

dr1fter · 2024-02-25 08:51:34

I had a similar issue (hanging applications the eventually loaded after some tens of seconds), which I could also fix (after finding this thread some months ago) by removing `xdg-desktop-portal-gnome`.

However, since yesterday (I rebooted my machine yesterday after ~4w w/o reboot), I have a similar (but different) issue:

Almost all applications seem to startup with usual loading performance; however, `nemo` (cinnamon's file-manager) will not start at all (it will hang for some few tens of seconds, and then terminate without ever showing up).

Using `strace nemo` gave me some output I am not sure how to interpret (the quoted error output repeats some times until the process finally terminates):

write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
recvmsg(8, {msg_namelen=0}, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}], 3, 0) = 1 ([{fd=3, revents=POLLIN}])
read(3, "\4\0\0\0\0\0\0\0", 8)          = 8
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}], 3, 0) = 0 (Timeout)
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}], 3, 0) = 0 (Timeout)
exit_group(1)                           = ?
+++ exited with 1 +++

On an additional note, google-chrome also seems to randomly freeze (it froze this tab/window, where I was/am typing this posting). This also never happened before (I did see such freezing after resuming from sleep sometimes, but this time my machine was not resuming from sleep).

I did not do any recent configuration changes, and also did not install or remove any packages in the past few weeks. I did however install an additional 32 GiB of main memory (upgrading my machine from 32 to 64 GiB in total; however, I would actually not have assumed this might be related to the issues I see).

There is one more thing that seems to be broken. I typically put my machine to standby using `systemctl suspend`. This command will no longer work. Instead, it will hang indefinitely, and also ignore e.g. CTRL-C input (thus requiring me to restart terminal). Using the desktop's GUI button for standby will work, though.

Any help very appreciated.

seth · 2024-02-25 09:05:05

Please don't necrobump to hijack solved threads with a shopping list of issues…

Open a new thread, post the full strace (out of context FD 4 is meaningless, could be dbus)
The overall situation sounds like a dbus issue, so also add the outputs of "loginctl session status", "echo $DBUS_SESSION_BUS_ADDRESS" and your complete system journal (could be dbus-broker) there.

wrt your memory changes, configure the RAM for the most conservative timings and frequencies, but the issues seem a bit too consistent and deterministic for RAM errors.

ewaller · 2024-02-25 15:36:16

Closing this old thread.
dr1fter, as seth suggested, please start a new thread which you will own. If you've multiple issues, go ahead with multiple threads.

We ask that because the ultimate goal is for each thread to become a resource others can use to solve the same problem. If a thread has multiple issues the thread invariably devolves to a Gordian knot.

Arch Linux

#1 2023-09-04 17:52:14

[SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#2 2023-09-04 18:36:50

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#3 2023-09-04 19:07:06

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#4 2023-09-04 19:21:52

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#5 2023-09-04 19:24:27

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#6 2023-09-04 19:27:27

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#7 2023-09-04 19:37:29

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#8 2023-09-04 19:42:26

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#9 2023-09-04 19:44:57

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#10 2023-09-04 22:49:31

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#11 2023-09-05 06:01:11

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#12 2023-09-09 14:24:25

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#13 2023-09-09 14:52:15

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#14 2023-09-11 06:50:22

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#15 2023-09-11 10:28:04

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#16 2023-09-11 15:53:32

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#17 2024-02-25 08:51:34

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#18 2024-02-25 09:05:05

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

#19 2024-02-25 15:36:16

Re: [SOLVED] Firefox, Archive Manager, others, take 20+ seconds to load

Board footer