Slow App Launch (~2s) After Inactivity

Issues & Assistance
1

I’m hoping to get some expert insight into a persistent performance issue I’m facing on my fresh CachyOS GNOME installation. While the system is generally fast, I’m experiencing a consistent ~2-second delay when launching certain applications (like Nautilus, GNOME Text Editor, etc.) if they haven’t been used for a few minutes.

This is not a typical “cold start vs. hot start” issue. An application can be opened, closed (hot cache), and reopened instantly. However, if I wait for about 1 or 2 minutes without using it and try to launch it again, the 2-second delay returns. This points towards a service timing out and needing to be restarted.

I’ve done some troubleshooting but couldnt solve it.

System Specifications:

  • OS: CachyOS (Latest version, installed fresh)
  • Desktop Environment: GNOME
  • Hardware: Laptop with Hybrid Graphics (AMD iGPU + NVIDIA RTX 3050 dGPU)
  • Filesystem: BTRFS
  • Kernel: (The latest CachyOS kernel)

–
Here is a summary of the steps I have taken to diagnose this issue:

1. Ruled out common issues:

  • Conflicting Portals: My initial installation was a bit mixed. I have since completely purged all traces of Hyprland, KDE, and other conflicting xdg-desktop-portal backends. My system now only has xdg-desktop-portal and xdg-desktop-portal-gnome.
  • NVIDIA GPU Power Management: I suspected the NVIDIA dGPU was taking time to wake up. I enabled NVIDIA Persistence Mode (sudo nvidia-smi -pm 1). This had no effect on the delay.
  • Disk I/O: I used strace on Nautilus during a slow launch. The trace clearly showed that the delay was not due to disk I/O (read, openat calls were instant). The hang occurred during ppoll() system calls, indicating the process was waiting for an IPC response. A key hang was over 1.7 seconds:ppoll([...], 3, {tv_sec=1, tv_nsec=760607000}, NULL, 8) = 0 (Timeout) <1.769456>

2. Pinpointed the Culprit with dbus-monitor: This was the breakthrough. By running dbus-monitor --session | grep -A 2 "StartServiceByName", I could see exactly what was happening during the 2-second hang. After a few minutes of inactivity, launching Nautilus triggers a cascade of StartServiceByName calls for the entire GVFS (GNOME Virtual File System) ecosystem.

Here is the log from the exact moment of the slow launch:

`method call time=1756932591.503300 sender=:1.135 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.Daemon"
   uint32 0
--
method call time=1756932591.597096 sender=:1.135 -> destination=org.freedesktop.DBus serial=86 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.UDisks2VolumeMonitor"
   uint32 0
--
method call time=1756932591.628236 sender=:1.135 -> destination=org.freedesktop.DBus serial=97 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.MTPVolumeMonitor"
   uint32 0
--
method call time=1756932591.659362 sender=:1.135 -> destination=org.freedesktop.DBus serial=108 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.GPhoto2VolumeMonitor"
   uint32 0
--
method call time=1756932593.881059 sender=:1.135 -> destination=org.freedesktop.DBus serial=152 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.Daemon"
   uint32 0`

The time jump from ...2591 to ...2593 clearly shows the ~2 second delay is spent re-launching these core GVFS services.

3. Failed Attempts to Fix: Based on the finding, I tried to prevent these services from being terminated by D-Bus.

  • I tried systemctl --user mask gvfs-daemon.service ... but it had no effect.
  • I tried systemctl --user enable gvfs-daemon.service ... but this failed with an error stating that the service units have no [Install] section and are not meant to be enabled this way, confirming they are designed for D-Bus activation.