mate desktop icons slow to load

buzzwallard · 2021-07-08 19:37:45

Desktop loads as usual but icons take 3-4 minutes to appear.

The two lightdm.log files have different output around the creation of the lightdm-data/<user> directory

/var/log/lightdm/lightdm.log

[+4.47s] DEBUG: Seat seat0: Session authenticated, running command
[+4.47s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[+4.47s] DEBUG: Session pid=573: Running command /etc/lightdm/Xsession mate-session

[+4.47s]>>>>>>>>>>>>>>> DEBUG:[Creating shared data directory /var/lib/lightdm-data/stephen

[+4.47s] DEBUG: Session pid=573: Logging to .xsession-errors
[+4.58s] DEBUG: Activating VT 7
[+4.58s] DEBUG: Activating login1 session 1
[+4.58s] DEBUG: Seat seat0 changes active session to 1
[+4.58s] DEBUG: Session 1 is already active

~/cache/lightdm/log/lightdm.log

[+0.37s] DEBUG: Session pid=5036: Not setting XDG_VTNR
[+0.37s] DEBUG: Session pid=5036: Running command /etc/lightdm/Xsession mate-session

[+0.37s] DEBUG: Creating shared data directory /var/lib/lightdm-data/stephen
[+0.37s>>>>>>>>>>>>>>>>>] WARNING: Could not create user data directory /var/lib/lightdm-data/stephen: Error creating directory /var/lib/lightdm-data/stephen: Permission denied

[+0.37s] DEBUG: Session pid=5036: Logging to .xsession-errors

The journal adds nothing new.

journalctl -b -u lightdm

:> journalctl -b -u lightdm
-- Journal begins at Sun 2021-06-13 20:00:29 PDT, ends at Thu 2021-07-08 12:25:21 PDT. --
Jul 08 11:50:11 asus systemd[1]: Starting Light Display Manager...
Jul 08 11:50:11 asus lightdm[466]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Ac>
Jul 08 11:50:11 asus systemd[1]: Started Light Display Manager.
Jul 08 11:50:15 asus lightdm[573]: pam_succeed_if(lightdm-autologin:auth): requirement "user ingroup autologin" was met by user "stephen"
Jul 08 11:50:15 asus lightdm[573]: gkr-pam: no password is available for user
Jul 08 11:50:15 asus lightdm[573]: pam_systemd_home(lightdm-autologin:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Jul 08 11:50:15 asus lightdm[573]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Ac>
Jul 08 11:50:15 asus lightdm[573]: pam_unix(lightdm-autologin:session): session opened for user stephen(uid=1000) by (uid=0)
Jul 08 11:50:15 asus lightdm[573]: pam_env(lightdm-autologin:session): deprecated reading of user environment enabled
Jul 08 11:50:15 asus lightdm[573]: gkr-pam: gnome-keyring-daemon started properly

seth · 2021-07-08 20:59:35

Why do you think the lightdm logs would be relevant when the issue is w/ your desktop session (in particular it seems the desktop shell and it's setup - so most likely "caja")?

buzzwallard · 2021-07-08 23:17:17

seth wrote:

Why do you think the lightdm logs would be relevant when the issue is w/ your desktop session (in particular it seems the desktop shell and it's setup - so most likely "caja")?

Ignorance. Plain and simple and no bones about it, just sheer bone-headed ignorance. In the light of your comment, it is the only explanation I can think of.

So following up on your lead re: desktop shell , I have bullied my way in and

- disabled the compositor (no effect but it was just a hunch anyway so don't ask me why)
- selected the Marco without compositor
- deleted the ~/.config/caja directory (ditto)

None of them did any good and some did bad.

Perhaps I should try another window manager?

seth · 2021-07-09 07:41:23

I'd start by looking at the session journal…
Also "compositor" - maybe elaborate on the issue.
Afaiu the sesssion starts and everything comes up nicely (panel, wallpaper…) but the "desktop icons" which have MINUTES of delay.
Does that mean there're no icons on the desktop (what about the panel) at all or do you see some placeholders?

When you restart "caja", do the icons show up immediately (and does the process yell warnings at you)?

buzzwallard · 2021-07-09 16:22:17

seth wrote:

I'd start by looking at the session journal…

I don't know where or how to access the session journal. I've looked through the journalctl output and see nothing I recognize as 'session'. I've looked at /var/log/journal/user-*.journal but I don't know how to read the content.

seth wrote:

Also "compositor" - maybe elaborate on the issue.

I was thinking that since the compositor is a layer of processes above the minimum required by the DM I would eliminate that extra.

seth wrote:

Afaiu the sesssion starts and everything comes up nicely (panel, wallpaper…) but the "desktop icons" which have MINUTES of delay.
Does that mean there're no icons on the desktop (what about the panel) at all or do you see some placeholders?

Your understanding is correct. Panels, wallpaper, menus all visible. The Desktop has icons to show but they do not show for 2-3 minutes (approx).

seth wrote:

When you restart "caja", do the icons show up immediately (and does the process yell warnings at you)?

Once the icons have shown a restart of caja is immediate and complete. On the other hand, caja will not open before the icons have shown. Having requested caja from the commandline there is no response until the caja window and the icons appear in the same instant. No placeholders. Empty space.

seth · 2021-07-09 16:36:51

journalctl -b --user

Caja hangs for somereason™ - hopefully recorded in the journal.

buzzwallard · 2021-07-10 17:14:02

seth wrote:

journalctl -b --user
Caja hangs for somereason™ - hopefully recorded in the journal.

Nothing in that journal. In fact the journal entries for --user stop before the desktop loads. The icons appear minutes after the last log entry.

Also, restarting caja pkill caga clears the desktop and then restores it immediately as caja comes up again.

seth · 2021-07-10 17:47:52

In fact the journal entries for --user stop before the desktop loads.

loginctl session-status

?

buzzwallard · 2021-07-11 14:38:54

seth wrote:

loginctl session-status

?

1 - stephen (1000)
	   Since: Sun 2021-07-11 07:33:11 PDT; 29s ago
	  Leader: 593 (lightdm)
	    Seat: seat0; vc7
	 Display: :0
	 Service: lightdm-autologin; type x11; class user
	 Desktop: mate
	   State: active
	    Unit: session-1.scope
		  |- 593 lightdm --session-child 12 15
		  |- 615 /usr/bin/gnome-keyring-daemon --daemonize --login
		  |- 619 mate-session
		  |- 670 /usr/lib/mate-settings-daemon/mate-settings-daemon
		  |- 678 marco
		  |- 708 mate-panel
		  |- 712 /usr/lib/mate-settings-daemon/msd-locate-pointer
		  |- 738 /usr/bin/caja
		  |- 746 /usr/bin/python3 /usr/share/system-config-printer/applet.py
		  |- 749 /usr/lib/mate-polkit/polkit-mate-authentication-agent-1
		  |- 993 /usr/bin/mate-terminal --disable-factory
		  |-1024 bash
		  `-1118 loginctl session-status

Jul 11 07:33:11 asus systemd[1]: Started Session 1 of user stephen.
Jul 11 07:33:13 asus mate-session[619]: WARNING: Unable to find provider '' of required component 'dock'
Jul 11 07:33:15 asus gnome-keyring-daemon[615]: The PKCS#11 component was already initialized
Jul 11 07:33:15 asus gnome-keyring-daemon[615]: The Secret Service was already initialized
Jul 11 07:33:15 asus gnome-keyring-daemon[615]: The SSH agent was already initialized

I ran this before and after the appearance of the icons. The only diff was the timestamp of the run. Which was only a minute actually, not three as initially reported.

seth · 2021-07-11 15:18:57

/usr/share/xsessions/mate.desktop only executes mate-session, but your session runs /usr/bin/gnome-keyring-daemon ahead.
=> How? In particular, do you https://wiki.archlinux.org/title/Displa … _a_session ?

buzzwallard · 2021-07-11 16:55:41

seth wrote:

/usr/share/xsessions/mate.desktop only executes mate-session, but your session runs /usr/bin/gnome-keyring-daemon ahead.
=> How? In particular, do you https://wiki.archlinux.org/title/Displa … _a_session ?

[Seat:*]
session-wrapper=/etc/lightdm/Xsession

??

seth · 2021-07-11 20:42:07

This doesn't run the gnome-keyring-daemon.

grep keyring ~/.* ~/* /etc/profile /etc/profile/*

buzzwallard · 2021-07-12 17:38:50

cat a

seth wrote:

This doesn't run the gnome-keyring-daemon.
grep keyring ~/.* ~/* /etc/profile /etc/profile/*

I'm lost now - sorry.

1. You ask if I am running ~/.xinitrc as a session. I did not have xorg-xinit installed. Installed it without effect. Though I am not clear what to expect here.
2. gnome-keyring-daemon is running before mate-session although there is no obvious reason why.

To sort this out you suggest

grep keyring ~/.* ~/* /etc/profile /etc/profile/*

This finds no occurrences. The only output is the errors about files being directories or not being directories.

Can you see my confusion

seth · 2021-07-12 19:09:53

The underlying question is how exactly the session is started and whether it includes some dbus-lunch etc (which might offset the session bus availability)

Though now that you've xinit installed, you could try to disable lightdm, setup your ~/.xinitrc for "exec mate-session" (please make sure to see http://wiki.archlinux.org/index.php/Xinit#xinitrc for a proper xinitrc, you need to include some files and be aware that nothing after the first "exec" line will be run) and run "xinit" from the multi-user.target (console login) to see whether:
a) it also causes a slow caja start
b) "/usr/bin/gnome-keyring-daemon --daemonize --login" somehow comes up as well (eg. from mate-session)

buzzwallard · 2021-07-13 13:50:53

seth wrote:

The underlying question is how exactly the session is started and whether it includes some dbus-lunch etc (which might offset the session bus availability)
Though now that you've xinit installed, you could try to disable lightdm, setup your ~/.xinitrc for "exec mate-session" (please make sure to see http://wiki.archlinux.org/index.php/Xinit#xinitrc for a proper xinitrc, you need to include some files and be aware that nothing after the first "exec" line will be run) and run "xinit" from the multi-user.target (console login) to see whether:
a) it also causes a slow caja start
b) "/usr/bin/gnome-keyring-daemon --daemonize --login" somehow comes up as well (eg. from mate-session)

seth wrote:

The underlying question is how exactly the session is started and whether it includes some dbus-lunch etc (which might offset the session bus availability)
Though now that you've xinit installed, you could try to disable lightdm, setup your ~/.xinitrc for "exec mate-session" (please make sure to see http://wiki.archlinux.org/index.php/Xinit#xinitrc for a proper xinitrc, you need to include some files and be aware that nothing after the first "exec" line will be run) and run "xinit" from the multi-user.target (console login) to see whether:
a) it also causes a slow caja start
b) "/usr/bin/gnome-keyring-daemon --daemonize --login" somehow comes up as well (eg. from mate-session)

a) Still have the slow caja start
b) The keyring daemon starts *after* the mate-session start.

I may have not configured properly though. After a couple of boots my desktop settings were corrupted (or lost) -- fixed with a couple clicks in mate-tweak but still a worry...

One of my desktop icons is a link to a remote drive so I removed that -- to no effect. I notice too that the remote drive is accessible well before the desktop icons appear.

Even so, I wonder if caja is trying to load or test remote links in the background.

seth · 2021-07-13 14:09:38

You could https://wiki.archlinux.org/title/MATE#P … he_desktop to defer it's initial invocation and run that out of an interactive shell

strace -t -f caja | tee /tmp/caja.strace 2>&1

buzzwallard · 2021-07-14 13:36:55

seth wrote:

You could https://wiki.archlinux.org/title/MATE#P … he_desktop to defer it's initial invocation and run that out of an interactive shell
strace -t -f caja | tee /tmp/caja.strace 2>&1

Even with desktop icons off, mate-session starts caja as the desktop opens. There is no caja window visible but there is a caja process child to mate-session.

Running the strace in a terminal window opened as soon as the desktop appears produces the following output but the caja window (and desktop icons) do not appear until after a minute or so.

https://pastebin.com/VYnHQj44

seth · 2021-07-15 07:28:19

The timestamp is always the same and the process terminates pretty much immeditately - you probably ran it on a new process (teh command above) instead of attaching to the running caja process?

strace -t -f -p $(pidof caja) 2>&1 | tee /tmp/caja.strace

buzzwallard · 2021-07-15 17:24:28

I can no longer replicate the issue.

I have been using Arch LTS exclusively, but for testing I added a boot entry for linux. When I booted into that entry the icons came up with the panel. Switching back into LTS, the icons again come up immediately.

I can't class this as 'solved' because I don't understand the 'solution'.

seth · 2021-07-15 19:01:42

"Co·in·ci·dence" - did you *only* install the other kernel or maybe update a bunch of packages along?

buzzwallard · 2021-07-15 19:20:42

seth wrote:

"Co·in·ci·dence" - did you *only* install the other kernel or maybe update a bunch of packages along?

Ah there.

I'd installed the main kernel along with LTS but had entered only the LTS to the boot menu. So there wasn't a big update or rebuild there.

I'm waiting on a new version of mate-panel so I've been checking for updates every day and updating except for a couple packages I'm holding back. So there wasn't a big change.

The miraculous fix happened yesterday so here are yesterday's updates as recorded in pacman.log

[2021-07-14T15:16:22-0700] [PACMAN] Running 'pacman -Syy'
[2021-07-14T15:16:22-0700] [PACMAN] synchronizing package lists
[2021-07-14T15:16:29-0700] [PACMAN] Running 'pacman -Syu'
[2021-07-14T15:16:29-0700] [PACMAN] synchronizing package lists
[2021-07-14T15:16:30-0700] [PACMAN] starting full system upgrade
[2021-07-14T15:16:50-0700] [ALPM] transaction started
[2021-07-14T15:16:50-0700] [ALPM] upgraded adobe-source-sans-fonts (3.042-1 -> 3.046-1)
[2021-07-14T15:16:50-0700] [ALPM] upgraded ca-certificates-mozilla (3.67-1 -> 3.68-1)
[2021-07-14T15:16:50-0700] [ALPM] upgraded nss (3.67-1 -> 3.68-1)
[2021-07-14T15:16:50-0700] [ALPM] upgraded firefox (89.0.2-1 -> 90.0-1)
[2021-07-14T15:16:50-0700] [ALPM] transaction completed
[2021-07-14T15:16:50-0700] [ALPM] running '30-systemd-update.hook'...
[2021-07-14T15:16:50-0700] [ALPM] running '40-update-ca-trust.hook'...
[2021-07-14T15:16:51-0700] [ALPM] running 'fontconfig.hook'...
[2021-07-14T15:16:51-0700] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-07-14T15:16:51-0700] [ALPM] running 'update-desktop-database.hook'...

Do you see anything there that would explain the fix?

seth · 2021-07-15 19:32:22

No, but this here could be relevant:

[2021-07-14T15:16:51-0700] [ALPM] running 'gtk-update-icon-cache.hook'...

buzzwallard · 2021-07-15 22:07:58

seth wrote:

No, but this here could be relevant:
[2021-07-14T15:16:51-0700] [ALPM] running 'gtk-update-icon-cache.hook'...

Ah. Good spotting.

It has run a few times since we started this conversation

[2021-07-08T15:46:55-0700] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-07-08T16:11:23-0700] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-07-11T08:11:11-0700] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-07-11T08:41:24-0700] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-07-12T15:14:21-0700] [ALPM] running 'gtk-update-icon-cache.hook'...
[2021-07-14T15:16:51-0700] [ALPM] running 'gtk-update-icon-cache.hook'...

What might it have done extra that last time?

This hook is attached to gtk-update-icon-cache

From the man page :

 gtk4-update-icon-cache creates mmapable cache files for icon themes.

       It expects to be given the PATH to an icon theme directory containing
       an index.theme, e.g.  /usr/share/icons/hicolor, and writes a
       icon-theme.cache containing cached information about the icons in the
       directory tree below the given directory.

Am I correct in thinking that for this to be relevant here we would find a cache directory child to Desktop?

Or -- where can I find that 'hook'ed script.

Last edited by buzzwallard (2021-07-15 22:08:46)

seth · 2021-07-16 06:50:48

/usr/share/libalpm/hooks/gtk-update-icon-cache.hook
/usr/share/libalpm/scripts/gtk-update-icon-cache

It runs on any directory that gets touched in /usr/share/icons/ so it *might* have cached other paths/themes before (and now hit on /usr/share/icons/hicolor/ for the FF update)

Arch Linux

#1 2021-07-08 19:37:45

mate desktop icons slow to load

#2 2021-07-08 20:59:35

Re: mate desktop icons slow to load

#3 2021-07-08 23:17:17

Re: mate desktop icons slow to load

#4 2021-07-09 07:41:23

Re: mate desktop icons slow to load

#5 2021-07-09 16:22:17

Re: mate desktop icons slow to load

#6 2021-07-09 16:36:51

Re: mate desktop icons slow to load

#7 2021-07-10 17:14:02

Re: mate desktop icons slow to load

#8 2021-07-10 17:47:52

Re: mate desktop icons slow to load

#9 2021-07-11 14:38:54

Re: mate desktop icons slow to load

#10 2021-07-11 15:18:57

Re: mate desktop icons slow to load

#11 2021-07-11 16:55:41

Re: mate desktop icons slow to load

#12 2021-07-11 20:42:07

Re: mate desktop icons slow to load

#13 2021-07-12 17:38:50

Re: mate desktop icons slow to load

#14 2021-07-12 19:09:53

Re: mate desktop icons slow to load

#15 2021-07-13 13:50:53

Re: mate desktop icons slow to load

#16 2021-07-13 14:09:38

Re: mate desktop icons slow to load

#17 2021-07-14 13:36:55

Re: mate desktop icons slow to load

#18 2021-07-15 07:28:19

Re: mate desktop icons slow to load

#19 2021-07-15 17:24:28

Re: mate desktop icons slow to load

#20 2021-07-15 19:01:42

Re: mate desktop icons slow to load

#21 2021-07-15 19:20:42

Re: mate desktop icons slow to load

#22 2021-07-15 19:32:22

Re: mate desktop icons slow to load

#23 2021-07-15 22:07:58

Re: mate desktop icons slow to load

#24 2021-07-16 06:50:48

Re: mate desktop icons slow to load

Board footer