Bug 2305707 - Gnome Files, Terminal, Text Editor taking 20s to launch in Live instance
Summary: Gnome Files, Terminal, Text Editor taking 20s to launch in Live instance
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 41
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: GNOME SIG Unassigned
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F41BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2024-08-19 12:19 UTC by Jens Petersen
Modified: 2024-08-31 15:13 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-08-31 15:13:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2024-08-19 12:19:08 UTC
In F41 Workstation Live instance, some gnome apps take >20s
to appear the first time one tries to launch them in a gnome-session.

Reproducible: Always

Steps to Reproduce:
1. Boot Fedora-Workstation-Live-x86_64-41-20240818.n.0.iso VM
(I am using virt-manager)
2. Select "Try Fedora"
3. Launch "Files", "Terminal" or "Text Editor" from the gnome shell overview
Actual Results:  
1. wait cursor appears and then disappears after a while
2. app appears finally after over 20s delay


Expected Results:  
App to start in a few seconds

I can't reproduce in an installation of WS.

On second attempt the app launches immediately.

Comment 1 Fedora Admin user for bugzilla script actions 2024-08-19 12:19:15 UTC
This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/.

This issue should only be kept open if it:

1. Relates to Fedora packaging or integration with other Fedora components
2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

If this issue isn't needed for either of these two reasons, please:

 * create an issue with GNOME
 * add a link to the GNOME issue here
 * close this issue as CLOSED/UPSTREAM

Thank you!

Comment 2 Matthias Clasen 2024-08-19 13:32:14 UTC
sysprof might tell you where the time is spent during startup

Comment 3 Jens Petersen 2024-08-19 13:46:37 UTC
Matthias told me in matrix:

I ususally use sysprof-cli: sysprof-cli -- /path/to/app
and then open the resulting capture file in sysprof

Comment 4 Jens Petersen 2024-08-19 14:16:15 UTC
I tried a bit: eg I installed xterm to run sysprof,
but once the xterm already appears,
other apps start immediately.

Is there any way I can run a desktop app from a vt console?

Comment 5 Jens Petersen 2024-08-19 16:01:56 UTC
Hm, I tried running the gnome-shell looking-glass or "run prompt"...
but that also seems to prevent the delay happening.

Comment 6 František Zatloukal 2024-08-19 18:32:00 UTC
Discussed during the 2024-08-19 blocker review meeting: [1]

The decision to classify this bug as a AcceptedFreezeException (Beta) was made:

"This is accepted as it's clearly annoying and cannot be fixed with an update (as it affects the live media)."

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-08-19/f41-blocker-review.2024-08-19-15.59.log.html

Comment 7 Benjamin Otte 2024-08-21 20:01:40 UTC
This is very likely the initial shader compilation of GTK. Once the first app has finished starting up, shaders will be cached.

Though that should not take 20s - maybe around 1-2s. Are you on some really slow hardware or using some obscure GPU?

Comment 8 Matthias Clasen 2024-08-21 20:12:52 UTC
That theory could be confirmed by checking that removing ~/.cache/gtk-4.0/vulkan-pipeline-cache makes the launch of the app slow again.

Comment 9 Steve 2024-08-21 22:43:28 UTC
(In reply to Jens Petersen from comment #4)
> Is there any way I can run a desktop app from a vt console?

Try "strace -r" or "strace -T":
strace (1)           - trace system calls and signals

Comment 10 Steve 2024-08-21 23:22:51 UTC
(In reply to Jens Petersen from comment #0)
> 1. Boot Fedora-Workstation-Live-x86_64-41-20240818.n.0.iso VM
> (I am using virt-manager)

I don't see any significant startup delay for Terminal, File Manager, or Text Editor immediately after booting a VM with:

Fedora-Workstation-Live-x86_64-41-20240819.n.0.iso

"Fedora Linux 40" is the "Operating System" under "OS information".

The VM is configured with 8192 MiB memory, 3 CPUs, and no storage.

Tried both "qemu:///session" and "qemu:///system".

Host is F40 Xfce with:

$ rpm -q virt-manager libvirt-daemon-driver-qemu qemu-kvm
virt-manager-4.1.0-5.fc40.noarch
libvirt-daemon-driver-qemu-10.1.0-3.fc40.x86_64
qemu-kvm-8.2.2-1.fc40.x86_64

$ uname -r
6.10.5-200.fc40.x86_64

Comment 11 Steve 2024-08-22 00:05:31 UTC
(In reply to Steve from comment #10)
> I don't see any significant startup delay for Terminal, File Manager, or Text Editor immediately after booting a VM with:
> 
> Fedora-Workstation-Live-x86_64-41-20240819.n.0.iso
                                           ^

I tried Fedora-Workstation-Live-x86_64-41-20240818.n.0.iso, and File Manager takes 28 seconds to start.
                                                 ^

The other two apps start in about 3 to 4 seconds.

BTW, the firstboot sequence is significantly different between the two versions.

Comment 13 Jens Petersen 2024-08-22 07:10:06 UTC
Thanks Steve!  Very useful info.
Staring at the list of updated packages: not sure which update might have fixed this,
gnome-initial-setup perhaps?? 

Anyway I agree I just tried Fedora-Workstation-Live-x86_64-41-20240821.n.0.iso
and indeed it looks to be that the problem is fixed already somehow, so yay I guess.

Comment 14 Steve 2024-08-22 13:05:27 UTC
Jens: Thanks for reporting that Fedora-Workstation-Live-x86_64-41-20240821.n.0.iso works as expected. I can confirm that.

The gnome-initial-setup changelog shows that a "live mode patch" was dropped:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2531892

Comment 15 Steve 2024-08-22 13:33:36 UTC
Dropping that "live mode patch" removed 2859 lines:
https://src.fedoraproject.org/rpms/gnome-initial-setup/c/0c755d6a334122ab991cee40687d5447d46a8fbd?branch=f41

Comment 16 Adam Williamson 2024-08-31 15:13:43 UTC
If it's fixed let's close it as fixed. If someone still sees the problem we can re-open it.


Note You need to log in before you can comment on or make changes to this bug.