You are not logged in.
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?
Offline
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)
Offline
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)
Offline
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.
Offline
Thanks! TIL about SysRq
Here are the journal entries: https://0x0.st/XoKs.txt
Offline
Seems the latest kernel update fixed it. At least for me.
Offline
@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)
Offline
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'
Offline
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)
Offline
You posted one before - was that from an unsuccesful login and did "pkcs11" fail?
Offline
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)
Offline
"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
Offline
"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?
Offline
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.
Offline
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.
Offline
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)
Offline
It' probably something else then, do you have a journal from a bad boot?
Offline
The kernel update didn't fix it on my system. Here's the journal for a failed boot attempt: https://0x0.st/XoJ6.txt
Offline
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
Offline
It started acting up again, I had three freezes on a row today. The latest one here: https://0x0.st/XoGY.txt
Offline
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
Offline
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
Offline
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
Offline
@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.
Offline
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)
Offline