Gnome freezes upon login

dllmr · 2024-04-06 21:36:07

Interesting theory about time syncs @seth, but it doesn't feel right from my experience. The problem seems just as likely when rebooting after a settings change as when the system has been powered off overnight, plus I'm on wired Ethernet (not wifi) and I've never seen my RTC out by more than a second or so.

Yes, LightDM can start GNOME with either X11 or Wayland, though unlike GDM I guess there's no Wayland session support within the DM itself which perhaps could be a factor?

seth · 2024-04-07 07:31:08

I guess there's no Wayland session support within the DM itself which perhaps could be a factor?

It would be but for the otehr cases where it's the exact opposide and GDM/wayland seems to mitigate the issue.
Replacing GDM will more likely be able to sidestep the screenlocker, because that feature can now no longer be provided by GDM.

This is going to be some race condition during the gnome startup.
Another thread, which is however somewhat nvidia specific and deals w/ gnome on X11 and has different journal patterns…, figured that autostarting applications crash gnome on startup or if they're started tooearly™, but autostarting gnome-terminal would alleviate/prevent that.
There's been some upstream action wrt. restructuring xsync calls (what however would only be -mildly- relevant if the autostarting client on wayland would be an xwayland one)

pvdrz · 2024-04-17 17:33:26

Hi everyone,

I have the same issue as you but on my case I have an ethernet connection and NetworkManager connects succesfully before I even log in so I suspect that connecting to the network before log in won't fix the issue.

I had this theory about partitions being mounted to a folder owned by the user as the culprit and I'd like to know if any of you have such configuration.

Edit: here is the jorunal for one of the freezes https://0x0.st/XoHY.txt

Last edited by pvdrz (2024-04-17 17:37:13)

seth · 2024-04-17 22:08:57

Tails in

Apr 17 09:54:16 retribution systemd-logind[1930]: New session 3 of user christian.
Apr 17 09:54:16 retribution systemd[1]: Created slice User Slice of UID 1000.
Apr 17 09:54:16 retribution systemd[1]: Starting User Runtime Directory /run/user/1000...
Apr 17 09:54:16 retribution systemd[1]: Finished User Runtime Directory /run/user/1000.
Apr 17 09:54:16 retribution systemd[1]: Starting User Manager for UID 1000...
Apr 17 09:54:16 retribution (systemd)[2697]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal=[] user=[christian] ruser=[<unknown>] rhost=[<unknown>]
Apr 17 09:54:16 retribution (systemd)[2697]: pam_unix(systemd-user:session): session opened for user christian(uid=1000) by christian(uid=0)

did you resolve the freeze by pushing the power button?
(Don't. W/ the issue discussed here you should be able to change the VT (ctrl+alt+f3) and in doubt use the https://wiki.archlinux.org/title/Keyboa … el_(SysRq)
A hard reboot will lose the journal.

pvdrz · 2024-04-17 22:56:40

Thanks! TIL about SysRq

Here are the journal entries: https://0x0.st/XoKs.txt

brainiac · 2024-04-17 23:53:51

Seems the latest kernel update fixed it. At least for me.

seth · 2024-04-18 09:00:42

@pvdrz - what most people arefacing w/ gnome46:

Apr 17 17:52:38 retribution gnome-session[1989]: gnome-session-binary[1989]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Apr 17 17:52:38 retribution gnome-session-binary[1989]: WARNING: Could not retrieve current screensaver active state: Timeout was reached

(nb. that this is very likely just an indicator)

@brainiac, there're currently a series of apparently different "gnome freezes on session start" threads, down to bugs in the X11 implementation and in this case seemingly a race condition.
It is not *very* likely that a kernel update could address any of those highly gnome46 specific issues, but there previously were amdgpu related issues (probably concerning framebuffer updates because switching the VT forth and back would resolve those)

seth · 2024-04-18 09:29:51

Can anybody please check whether there're differences in "keyring … Failed with result" messages between good and bad login attempts?

grep -E 'keyring.*Failed with result'

brainiac · 2024-04-18 11:37:51

Succesful login.

Apr 18 13:41:16 b05 systemd[1357]: app-gnome-gnome\x2dkeyring\x2dsecrets-1565.scope: Failed with result 'resources'.
Apr 18 13:41:16 b05 systemd[1357]: app-gnome-gnome\x2dkeyring\x2dssh-1562.scope: Failed with result 'resources'.

Last edited by brainiac (2024-04-18 11:42:45)

seth · 2024-04-18 12:55:29

You posted one before - was that from an unsuccesful login and did "pkcs11" fail?

brainiac · 2024-04-18 13:32:58

I removed it because i was unsure... but if journalctl -b only shows the last boot it was succesful too. And pkcs11 failed there, yes.

Last edited by brainiac (2024-04-18 13:33:54)

seth · 2024-04-18 13:35:32

"journalctl -b" shows the current boot, but if you get successful session starts despite all keyring services flaring up, it's a red herring anyway

brainiac · 2024-04-18 14:53:50

seth wrote:

"journalctl -b" shows the current boot, but if you get successful session starts despite all keyring services flaring up, it's a red herring anyway

meaning?

seth · 2024-04-18 15:13:04

Another thread posted comparative journals and the keyring difference stuck out between a good and a bad login.
Gnome/GKR rather recently had issues itr and I had hoped it might be at the bottom of this (again) - but apparently it's not.

pvdrz · 2024-04-18 15:25:36

seth wrote:

Can anybody please check whether there're differences in "keyring … Failed with result" messages between good and bad login attempts?
grep -E 'keyring.*Failed with result'

I have the same entries for both good and bad login attempts.

Apr 17 17:52:36 retribution systemd[1900]: app-gnome-gnome\x2dkeyring\x2dsecrets-1999.scope: Failed with result 'resources'.
Apr 17 17:52:36 retribution systemd[1900]: app-gnome-gnome\x2dkeyring\x2dssh-2001.scope: Failed with result 'resources'.

regarding @brainiac assertion of the kernel update fixing this I'm not sure. I didn't experience any freezes this morning but it could be luck.

brainiac · 2024-04-18 15:45:04

regarding @brainiac assertion of the kernel update fixing this I'm not sure. I didn't experience any freezes this morning but it could be luck.

At least for me the problem came with the 6.8.6 kernel and disappeared with 6.8.7. And is consistently reproducible.

Last edited by brainiac (2024-04-18 15:49:13)

seth · 2024-04-18 20:00:38

It' probably something else then, do you have a journal from a bad boot?

pvdrz · 2024-04-20 16:06:15

The kernel update didn't fix it on my system. Here's the journal for a failed boot attempt: https://0x0.st/XoJ6.txt

seth · 2024-04-20 16:23:26

This here is still weird

Apr 19 11:37:44 retribution /usr/lib/gdm-wayland-session[1288]: dbus-daemon[1288]: [session uid=120 pid=1288] Activating service name='org.gnome.ScreenSaver' requested by ':1.20' (uid=120 pid=1449 comm="/usr/lib/gsd-power")
Apr 19 11:37:44 retribution /usr/lib/gdm-wayland-session[1288]: dbus-daemon[1288]: [session uid=120 pid=1288] Successfully activated service 'org.gnome.ScreenSaver'
Apr 19 11:37:54 retribution systemd[1916]: Starting GNOME FreeDesktop screensaver service...
Apr 19 11:37:54 retribution systemd[1916]: Started GNOME FreeDesktop screensaver service.
Apr 19 11:37:54 retribution systemd[1916]: Reached target GNOME FreeDesktop screensaver target.
Apr 19 11:37:54 retribution systemd[1916]: Created slice Slice /app/dbus-:1.2-org.gnome.ScreenSaver.
Apr 19 11:37:54 retribution systemd[1916]: Started dbus-:1.2-org.gnome.ScreenSaver@0.service.
Apr 19 11:37:55 retribution gnome-session[2007]: gnome-session-binary[2007]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Apr 19 11:37:55 retribution gnome-session-binary[2007]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Apr 19 11:38:05 retribution unknown[1494]: Error releasing name org.freedesktop.ScreenSaver: The connection is closed
Apr 19 11:38:05 retribution systemd[1916]: Stopped dbus-:1.2-org.gnome.ScreenSaver@0.service.

The screensaver starts and then there's a timeout after only 1s later on.

The screensaver issue pops up frequently but gitlab has only two entries, one being https://gitlab.gnome.org/GNOME/NetworkM … /issues/53 the other https://gitlab.gnome.org/GNOME/glib/-/issues/2597

https://wiki.archlinux.org/title/IPv6#Disable_IPv6
"ipv6.disable=1", https://wiki.archlinux.org/title/Kernel_parameters

ajje · 2024-04-22 08:33:26

It started acting up again, I had three freezes on a row today. The latest one here: https://0x0.st/XoGY.txt

seth · 2024-04-22 08:56:55

Just a hunch, what if you disable https://help.gnome.org/admin/system-adm … ts.html.en
Apparently it's being "revitalized", https://discourse.gnome.org/t/removing- … p-46/18624

pvdrz · 2024-04-22 16:39:02

It has become less frequent in my case but it still happens from time to time (it could be just statistical bias anyway). Here's the latest incident's journal: https://0x0.st/Xonu.txt

Muflone · 2024-04-22 19:22:13

it only happens in my system if I unplug the power cord and unlock the session in battery mode

During a workday I lock the session and unlock it again more than 30 times and not a single time happens with the power cord plugged, while in battery mode it happens the half of the times

seth · 2024-04-22 20:27:09

@pvdrz, "become less frequent" in response to what action?

Apr 22 11:33:22 retribution goa-daemon[2393]: /org/gnome/OnlineAccounts/Accounts/account_1707508323_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: No credentials found in the keyring (goa-error-quark, 4)

@Muflone, afaiu the general reports, this happens on actual logins, not when unlocking the session (a common denominator is that the screesaver state, ie. the lockability, cannot be queried) and from pvdrz's journal, there's little chance they ever run on battery
Do you have comparative journal?
This sounds more like some power saving mechanism kicks in and the CPU or GPU cannot recover.

superjcvd · 2024-04-29 18:01:53

Hello.

I have the exact same problem on a workstation with AMD Ryzen 5 5600X and Radeon RX 6600.

Something I noticed so far (maybe unrelated but funny):
- If I log to GDM by clicking on the prompt I have no freeze
- If I log to GDM by pushing Return or Tab keys on my keyboard I have the freeze

Maybe the freeze is linked to the mouse usage ?

Last edited by superjcvd (2024-04-29 18:02:35)

Arch Linux

#26 2024-04-06 21:36:07

Re: Gnome freezes upon login

#27 2024-04-07 07:31:08

Re: Gnome freezes upon login

#28 2024-04-17 17:33:26

Re: Gnome freezes upon login

#29 2024-04-17 22:08:57

Re: Gnome freezes upon login

#30 2024-04-17 22:56:40

Re: Gnome freezes upon login

#31 2024-04-17 23:53:51

Re: Gnome freezes upon login

#32 2024-04-18 09:00:42

Re: Gnome freezes upon login

#33 2024-04-18 09:29:51

Re: Gnome freezes upon login

#34 2024-04-18 11:37:51

Re: Gnome freezes upon login

#35 2024-04-18 12:55:29

Re: Gnome freezes upon login

#36 2024-04-18 13:32:58

Re: Gnome freezes upon login

#37 2024-04-18 13:35:32

Re: Gnome freezes upon login

#38 2024-04-18 14:53:50

Re: Gnome freezes upon login

#39 2024-04-18 15:13:04

Re: Gnome freezes upon login

#40 2024-04-18 15:25:36

Re: Gnome freezes upon login

#41 2024-04-18 15:45:04

Re: Gnome freezes upon login

#42 2024-04-18 20:00:38

Re: Gnome freezes upon login

#43 2024-04-20 16:06:15

Re: Gnome freezes upon login

#44 2024-04-20 16:23:26

Re: Gnome freezes upon login

#45 2024-04-22 08:33:26

Re: Gnome freezes upon login

#46 2024-04-22 08:56:55

Re: Gnome freezes upon login

#47 2024-04-22 16:39:02

Re: Gnome freezes upon login

#48 2024-04-22 19:22:13

Re: Gnome freezes upon login

#49 2024-04-22 20:27:09

Re: Gnome freezes upon login

#50 2024-04-29 18:01:53

Re: Gnome freezes upon login

Board footer