Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

seth · 2025-01-22 20:10:04

Most gnome users will fail to start gnome w/o GDM, give up, use GDM or abandon gnome and not face this.
According to https://peter.sh/experiments/chromium-c … -switches/ that's not a valid switch.

I noticed that playing videos (such as on Youtube) seems to be what triggers the issue.

Makes sense and proves the theory but if electron doesn't use xdg-screensaver (or any other external executable) you're not gonna be able to blunt this and will have to remove the inhibit before suspending.

Or you could try and see whether gsd-power is the culprit and block that: https://unix.stackexchange.com/question … ibit-block

bedtime · 2025-01-22 23:20:22

seth wrote:

Most gnome users will fail to start gnome w/o GDM, give up, use GDM or abandon gnome and not face this.

The problem persists with gdm as well, even when I did a stock Gnome install with EndeavorOS. A few hours ago I installed Debian 12 Gnome on a USB. The suspend worked fine. I then did a fully new install (not an upgrade) of Debian 13 (Testing) on that USB, and the suspend problems returned with Brave.

According to https://peter.sh/experiments/chromium-c … -switches/ that's not a valid switch.

Thanks for looking that up. I was having troubles running it, so that explains that.

Or you could try and see whether gsd-power is the culprit and block that: https://unix.stackexchange.com/question … ibit-block

I took away gsd-power's execution permissions, and that didn't work. Tried a bunch of stuff with dconf, inhibiting sleep and such. Nope.

This might just be hopeless for the time being.

Last edited by bedtime (2025-01-23 00:52:24)

seth · 2025-01-23 09:06:56

Ok, but then the most likely explanation is just that brave inhibits the screensaver and that results in preventing suspends as well.
What does the inhibitior list currently look like and can you suspend the system after terminating brave/chromium?

bedtime · 2025-01-23 19:56:59

seth wrote:

Ok, but then the most likely explanation is just that brave inhibits the screensaver and that results in preventing suspends as well.
What does the inhibitior list currently look like and can you suspend the system after terminating brave/chromium?

Before and after a successful suspend it looks like:

$ systemd-inhibit
WHO            UID  USER PID COMM           WHAT                                                     WHY                                       MODE 
NetworkManager 0    root 533 NetworkManager sleep                                                    NetworkManager needs to turn off networks delay
UPower         0    root 875 upowerd        sleep                                                    Pause device polling                      delay
user           1000 user 983 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                 block
user           1000 user 983 gsd-media-keys sleep                                                    GNOME handling keypresses                 delay
user           1000 user 914 gsd-power      sleep                                                    GNOME needs to lock the screen            delay

I noticed that the issue only happens on Brave when a video is being played (YouTube) in the browser.

I just installed the exact same setup on another machine and had the exact same issue. Tried with and without GDM. Also tried on Fedora. Same issue. I'm just surprised that others aren't complaining about this issue!

If you can steer me where to put out a bug report, I'm more than happy to fill it out.

seth · 2025-01-23 20:49:26

Why does gsd-power show up there when it's not executable?
The gnome-session-binary doesn't seem to inhibit the system, nor does brave?

I noticed that the issue only happens on Brave when a video is being played (YouTube) in the browser.

You mean *actively*? That's probably not a bug but a feature - the browser inhibits the screensaver so you can watch video w/o wiggling the mouse all the time.
The inhibition is oc. meant to prevent unexplicit/timer-based locks/suspends etc. but maybe not explcit ones.
That would be for gnome to ignore the inhibition when the user explicitly wants to lock/suspend the system.

bedtime · 2025-01-23 21:23:29

seth wrote:

Why does gsd-power show up there when it's not executable?

I had made it executable again since making it non-executable didn't work.

The gnome-session-binary doesn't seem to inhibit the system, nor does brave?

Maybe not. Not really sure.

I noticed that the issue only happens on Brave when a video is being played (YouTube) in the browser.
You mean *actively*? That's probably not a bug but a feature - the browser inhibits the screensaver so you can watch video w/o wiggling the mouse all the time.
The inhibition is oc. meant to prevent unexplicit/timer-based locks/suspends etc. but maybe not explcit ones.
That would be for gnome to ignore the inhibition when the user explicitly wants to lock/suspend the system.

Yes, actively.

Damn. I'm really sorry if I've just wasted your time then. Nonetheless, I don't see why a person can't just restart their computer while another application is running a video. If this was just stopping the screensaver, that would be seem fine to me.

But, you could easily be right. Maybe I've just got it in my head that it's supposed to work another way. I'm so used to watching YouTube and then just pressing hibernate so I can come back to the same spot on the video. Guess I'm lazy. Firefox allows this.

Anyways, I guess that settles that. Thanks for all your help. I've learned a lot from all the troubleshooting you gave me, so there has been some gain.

seth · 2025-01-24 15:44:30

The thread didn't start out with that problem and even if: it's certainly not desired behavior.
Explicit user demands should always override any kind of smart behavior. I'd say this is a genuine bug in gnome.

Does restarting also not work (not only hibernation)?

bedtime · 2025-01-24 16:42:16

seth wrote:

The thread didn't start out with that problem and even if: it's certainly not desired behavior.
Explicit user demands should always override any kind of smart behavior. I'd say this is a genuine bug in gnome.

The one thing that seems strange is just pressing the suspend/hibernate button and NOTHING happens. You'd think gnome would at least throw a popup saying that it couldn't suspend/hibernate due to an active process inhibiting it.

seth wrote:

Does restarting also not work (not only hibernation)?

I'm able to reboot the machine through the gnome menu when playing a video, so that works as expected. Closing my laptop lid whilst a video is playing also works as expected—stopping the video and sleeping and waking up with a paused video after a key is pressed. The only two things that I found not to work right now are suspend and hibernate.

Also, has there been any plans to fix arch's manual on launching gnome?
https://wiki.archlinux.org/title/GNOME#Manually

seth · 2025-01-24 23:13:40

So it preventes S4, but not S3?
The distinction then sounds deliberate.
But when you override that and hibernate the system it wakes and continues to play the video?

bedtime · 2025-01-25 00:49:10

seth wrote:

So it preventes S4, but not S3?
The distinction then sounds deliberate.

No, both suspend and hibernate do not work when the video is playing in Brave. Power off, Restart, and Logout work.

seth wrote:

But when you override that and hibernate the system it wakes and continues to play the video?

No, when there is a video running in brave and I execute:

systemctl suspend -i

or

systemctl hibernate -i

...the system suspends/hibernates, and when awoken the video is paused.

seth · 2025-01-25 14:40:49

Ok, then the gnome UI behavior is undesired but consistent.
File an upstream bug and argue that explicit user action trum… outweighs the inhibition or could at most be intercepted ("Are you sure?").

bedtime · 2025-01-25 20:07:43

seth wrote:

Ok, then the gnome UI behavior is undesired but consistent.
File an upstream bug and argue that explicit user action trum… outweighs the inhibition or could at most be intercepted ("Are you sure?").

Will do. Where would I submit the bug? Sorry, but I haven't posted a bug in years and haven't a clue, but I'm more than happy to do it.

...

A little unrelated, but at my work several people have been coming down with pneumonia, and I've been feeling quite under the weather lately, so if I'm late replying or kinda out of it, that's why.

seth · 2025-01-25 21:32:05

https://gitlab.gnome.org/GNOME/gnome-session/-/issues and let them take it to the more relevant project (idk where exactly this is falling apart or what's in ultimate charge here)
No worries about your responsiveness - it's not an obstacle to /me/

bedtime · 2025-01-31 18:11:12

seth wrote:

https://gitlab.gnome.org/GNOME/gnome-session/-/issues and let them take it to the more relevant project (idk where exactly this is falling apart or what's in ultimate charge here)
No worries about your responsiveness - it's not an obstacle to /me/

Here we go:

https://gitlab.gnome.org/GNOME/gnome-se … issues/143

Should be interesting to see how this turns out.

Arch Linux

#26 2025-01-22 20:10:04

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#27 2025-01-22 23:20:22

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#28 2025-01-23 09:06:56

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#29 2025-01-23 19:56:59

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#30 2025-01-23 20:49:26

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#31 2025-01-23 21:23:29

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#32 2025-01-24 15:44:30

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#33 2025-01-24 16:42:16

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#34 2025-01-24 23:13:40

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#35 2025-01-25 00:49:10

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#36 2025-01-25 14:40:49

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#37 2025-01-25 20:07:43

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#38 2025-01-25 21:32:05

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

#39 2025-01-31 18:11:12

Re: Gnome terminal takes about 30 seconds to load [STILL NOT SOLVED]

Board footer