On Sat, 28 Jun 2025 at 18:31:49 +0200, Ben Hutchings wrote:
On this desktop system /home is mounted from an NFS server. This was
usable in bookworm. After upgrading to trixie, the shell doesn't
appear for several minutes, and then takes over a minute to respond to
some buttons.
I'm not at all sure that this is really a gnome-shell problem: the fact
that various services' startups are timing out seems like it indicates
some lower-level problem. I suspect that gnome-shell functionality is
blocking on those services' startups, which would happen promptly under
normal circumstances.
I created a fresh account to test this in isolation from any special
configuration I have that might make this worse
One good place to start would be to create a similar fresh account with
an on-disk $HOME (but otherwise the same system-level configuration),
and see whether that is equally slow to start. If this is a fully
diskless system, it could be on tmpfs if necessary; or if it has a real
SSD/HDD, use that (perhaps below /var/local).
Assuming the on-disk or tmpfs $HOME is OK, the next step would be to
narrow down which part of the home directory causes trouble when located
on NFS, by making a hybrid home directory where the top-level directory
is on one storage type but ~/.cache, ~/.config and ~/.local are on the
other.
My first suspicion would be dconf (~/.cache/dconf, ~/.config/dconf)
which uses a format that is designed to be mmap'd; but perhaps that's a
red herring.
Since you've said that everything is much slower with localsearch-3
(formerly Tracker), please try without that - I suspect that it might
just be another victim of the same underlying issue, but I'm also
quite confident that localsearch/Tracker was not designed with a
high-latency $HOME in mind.
Jun 28 17:55:13 grosvenor dbus-daemon[22421]: [session uid=1003 pid=22421 pidfd=5]
Activating via systemd: service name='org.freedesktop.portal.Desktop'
unit='xdg-desktop-portal.service' requested by ':1.40' (uid=1003 pid=22662
comm="/usr/bin/gnome-software --gapplication-service")
Jun 28 17:55:13 grosvenor systemd[11109]: Starting xdg-desktop-portal.service -
Portal service...
This takes a while to start, most likely because it is waiting for the
portal backend x-d-p-gtk to initialize (the other major portal backend,
x-d-p-gnome, seems healthy). I suspect this might be either the root
cause, or at least several steps closer to the root cause than
gnome-shell is. Each of several IPC calls to x-d-p-gtk triggers another
attempt to start x-d-p-gtk, none of which is any more successful than
the first.
Jun 28 17:55:13 grosvenor dbus-daemon[22421]: [session uid=1003 pid=22421 pidfd=5]
Activating via systemd: service name='org.freedesktop.impl.portal.desktop.gtk'
unit='xdg-desktop-portal-gtk.service' requested by ':1.78' (uid=1003 pid=23000
comm="/usr/libexec/xdg-desktop-portal")
Jun 28 17:55:13 grosvenor systemd[11109]: Starting
xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation)...
Jun 28 17:55:13 grosvenor wireplumber[22963]: spa.bluez5: BlueZ system service
is not available
Jun 28 17:55:13 grosvenor wireplumber[22963]: [1:06:14.970013985] [22963] INFO
Camera camera_manager.cpp:327 libcamera v0.4.0
Jun 28 17:55:38 grosvenor xdg-desktop-por[23000]: Failed to create settings
proxy: Error calling StartServiceByName for
org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
...
Jun 28 17:57:13 grosvenor dbus-daemon[22421]: [session uid=1003 pid=22421
pidfd=5] Failed to activate service 'org.freedesktop.impl.portal.desktop.gtk':
timed out (service_start_timeout=120000ms)
I think this is a large part of the problem: xdg-desktop-portal-gtk,
from the package of the same name, is taking a very long time to start.
Please try re-running it in the session, with verbose log messages
(/usr/libexec/xdg-desktop-portal-gtk -vr), perhaps using strace or
dbus-monitor to see what it's doing and where it gets stuck.
If it starts promptly when restarted within the session itself, you
could try using an edited version of
/usr/lib/systemd/user/xdg-desktop-portal-gtk.service and saving it in
~/.config/systemd/user/ - in this case you would only want the -v option
(not -r), and it might also be useful to set
Environment=G_MESSAGES_DEBUG=all.
Jun 28 17:57:12 grosvenor dbus-daemon[22421]: [session uid=1003 pid=22421
pidfd=5] Failed to activate service 'org.gnome.Shell.Screencast': timed out
(service_start_timeout=120000ms)
This is clearly also getting stuck somewhere. As well as dconf, it makes
me wonder about perhaps GStreamer or Pipewire.
Jun 28 17:58:13 grosvenor systemd[11109]: localsearch-3.service: start
operation timed out. Terminating.
Jun 28 17:58:13 grosvenor systemd[11109]: localsearch-3.service: Killing
process 23480 (gst-plugin:sh0) with signal SIGKILL.
Jun 28 17:58:13 grosvenor systemd[11109]: localsearch-3.service: Failed with
result 'timeout'.
Jun 28 17:58:13 grosvenor systemd[11109]: Failed to start localsearch-3.service
- Tracker file system data miner.
This, too, makes me wonder about GStreamer.
smcv
