Bug#1108438: Very slow to start with NFS-mounted home directory

[Simon McVittie]

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