Created attachment 1953951 [details] dmesg Created attachment 1953951 [details] dmesg 1. Please describe the problem: I am using a docking station Thinkpad Pro Dock for my Thinkpad T450s, with two externals displays attached. When the notebook is attached to the docking station (lid closed), I start up my computer and after entering my credentials in GDM, the machine is being sent to proper standby. I can't really tell what to look for in the logs, please advise. dmesg shows 16:32:30 fedora kernel: thermal thermal_zone2: failed to read out thermal zone (-61) 16:32:33 fedora kernel: cdc_wdm 1-4:1.8: wdm_int_callback - 0 bytes 16:32:33 fedora kernel: cdc_wdm 1-4:1.5: wdm_int_callback - 0 bytes Not sure if related. 2. What is the Version-Release number of the kernel: 6.2.8-200.fc37.x86_64 I observed this bug since at least 6.0.x 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes, it did. Can't say when it stopped working. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1.) Turn off computer 2.) Turn on with thinkpad attaced to docking station 3.) Wait for GDM to show up 4.) Select user and enter password 5.) entering suspend to RAM 6.) After pressing the power button, PC wakes up and I am on my desktop. 5. Does this problem occur with the latest Rawhide kernel? Not yet tested 6. Are you running any modules that not shipped with directly Fedora's kernel?: virtualbox 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
and I see GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed from gdm-session-worker. not sure how to provide more useful debug information.
This sounds like it the laptop is suspending because the lid is closed and systemd does not see any external displays. I guess that the gdm -> gnome-user-session somehow causes the monitors to temporarily get seen as disconnected and then they get reprobed, lighting them up again. Not sure what we can do about this though...
Created attachment 1953953 [details] journal log here is a journal snipped that shows suspending and resuming. The suspend is happening at 16:32:05, resuming 16:32:30
thanks for your quick response Hans. just fyi, on older Fedora installs this never used to happen. (The setup hasn't changed in a while, notebook, docking station and displays are all a bit older) I don't understand the involvement of systemd (is is systemd-logind?) and why it wouldn't "see the displays"... they are on and showing first the boot process, then GDM's login screen. Also, once the notebook suspends, the external displays go in standby. As soon as I hit the power-button, the system resumes and systemd has no issues seeing those displays.
16:32:05 ModemManager: <info> [sleep-monitor] system is about to suspend 16:32:05 systemd-logind: Suspending... 16:32:05 systemd: Started xdg-document-portal.service - flatpak document portal service. 16:32:04 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.14-org.freedesktop.problems@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 16:32:04 systemd: Created slice system-dbus\x2d:1.14\x2dorg.freedesktop.problems.slice - Slice /system/dbus-:1.14-org.freedesktop.problems. 16:32:04 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.14-net.launchpad.backintime.serviceHelper@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 16:32:04 systemd: Started dbus-:1.14-net.launchpad.backintime.serviceHelper. 16:32:04 cupsd: REQUEST localhost - - "POST / HTTP/1.1" 200 363 Create-Printer-Subscriptions successful-ok 16:32:04 gnome-session-b: GnomeDesktop-WARNING: Could not create transient scope for PID 3692: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 3692 does not exist. 16:32:04 systemd: Started dbus-:1.2-org.gnome.ScreenSaver. 16:32:04 canberra-gtk-pl: Failed to play sound: File or data not found 16:32:04 systemd: Started app-gnome-libcanberra\x2dlogin\x2dsound-3578.scope - Application launched by gnome-session-binary. 16:32:04 kernel: rfkill: input handler disabled 16:32:04 systemd: Started org.gnome.SettingsDaemon.Housekeeping.service - GNOME maintenance of expirable data service. 16:32:04 gnome-session-b: GnomeDesktop-WARNING: Could not create transient scope for PID 3551: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 3551 does not exist. 16:32:04 vmware-user-sui: vmware-user: could not open /proc/fs/vmblock/dev 16:32:04 NetworkManager: <info> [1679927524.2868] agent-manager: agent[7482f4f262190790,:1.88/org.gnome.Shell.NetworkAgent/1000]: agent registered 16:32:04 abrt-applet: Failed to rename ‘/home/florian/.abrt/spool’ to ‘/home/florian/.cache/abrt/spool’: Datei oder Verzeichnis nicht gefunden 16:32:04 systemd: Started dbus-:1.2-org.freedesktop.problems.applet. 16:32:03 spice-vdagent: vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0 does not exist, exiting 16:32:03 systemd: Starting org.gnome.SettingsDaemon.MediaKeys.service - GNOME keyboard shortcuts service... 16:32:03 Xorg: (II) modeset(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e)
Ah I see that you have an old fashioned dock, I thought you were using a thunderbolt dock with DP-MST where sometimes when reprobing the monitors "disappear". AFAIK suspend is now a days managed by systemd and systemd will normally suspend a laptop with the lid closed (which is desirable). To avoid suspending when docked it checks for the presence of external monitors. But with an old-fashioned dock, with hardwired monitor connections, this behavior indeed is weird. Lets change the component to systemd and see if the systemd folks can help debug this.
Created attachment 1953987 [details] yet another log snippet for when systemd send the machine to sleep 20:02:15 systemd: Starting systemd-suspend.service - System Suspend... Resume is at 20:02:32
I have created another log file, see above, here are the moments before suspending: 20:02:15 kernel: Filesystems sync: 0.025 seconds 20:02:15 kernel: PM: suspend entry (deep) 20:02:15 systemd-sleep: Entering sleep state 'suspend'... 20:02:15 systemd: Starting systemd-suspend.service - System Suspend... 20:02:15 systemd-logind: Delay lock is active (UID 1000/florian, PID 3426/gnome-shell) but inhibitor timeout is reached. 20:02:14 gdm: Gdm: Child process -2350 was already dead. 20:02:14 systemd-logind: Removed session c1. 20:02:14 systemd: session-c1.scope: Consumed 5.546s CPU time. 20:02:14 polkitd: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.34, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) 20:02:14 systemd-logind: Session c1 logged out. Waiting for processes to exit. 20:02:14 gdm-session-wor: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Please let me know what else is required to debug this. thank you.
the part that also surprised me: when I resume, I am thrown at the desktop, not back to locl screen. When I do an intentional suspend I usually back at the lock screen after resuming, not so here.
Please show the output of: busctl introspect org.freedesktop.login1 /org/freedesktop/login1|grep -Ei 'dock|handle' Also please attach the full log starting at the boot and ending after the (unexpected) suspend event. (It's really hard to say anything about *why* the suspend happened if the log starts at the point of suspend.)
# busctl introspect org.freedesktop.login1 /org/freedesktop/login1|grep -Ei 'dock|handle' .BlockInhibited property s "handle-power-key:handle-suspend-key:ha… emits-change *.Docked property b true -* .HandleHibernateKey property s "hibernate" const .HandleHibernateKeyLongPress property s "ignore" const .HandleLidSwitch property s "suspend" const *.HandleLidSwitchDocked property s "ignore" const* .HandleLidSwitchExternalPower property s "" const .HandlePowerKey property s "poweroff" const .HandlePowerKeyLongPress property s "ignore" const .HandleRebootKey property s "reboot" const .HandleRebootKeyLongPress property s "poweroff" const .HandleSuspendKey property s "suspend" const .HandleSuspendKeyLongPress property s "hibernate" const
> *.Docked property b true > *.HandleLidSwitchDocked property s "ignore" So it seems logind thinks the laptop is docked, and is configured to do nothing when docked. You mentioned that the issue occurs after logging in, which is when gnome-shell takes over the management of suspend. I'm starting to think that the issue might be in gnome-shell. Full logs (as mentioned above) would be useful.
Created attachment 1954127 [details] full system log Full system log from boot to suspend
I just realized that for whatever reason GDM was set to login to "Gnome on Xorg". Once I change this to the default Wayland session, the bug does not occur anymore, no more suspending after login. So, it's somehow related to Xorg, maybe a similar condition as described in https://bugzilla.redhat.com/show_bug.cgi?id=2182093#c2 is present.
I suspect that the difference between Xorg and Wayland is in timing or in some detail of operation that makes the issue harder to hit. The logging in logind is bad, it just doesn't contain enough information to figure out what is going on, but I suspect that we should wait before acting on a lid switch event. We have had a bug open about this for years: https://github.com/systemd/systemd/issues/16045 We can keep this open, but realistically it's unlikely to be fixed any time soon. If Wayland works for you, this is a good-enough workaround.
It'd argue Wayland is not permanent solution as it's not offering quite the same experience just yet (some apps not fully supported). But this helped for me, setting: HandleLidSwitchExternalPower=ignore in: /etc/systemd/logind.conf
(In reply to Marko Bevc from comment #16) > HandleLidSwitchExternalPower=ignore > in: /etc/systemd/logind.conf In my use case this workaround wouldn't work because when my notebook isn't docked but on external power I want the OS to suspend upon lid-close (and ask me for a password when resuming on lid open)
I think this would only affect when you're on external power, from the docs: "if the system is on external power the action (if any) specified by HandleLidSwitchExternalPower= occurs; otherwise the HandleLidSwitch= action occurs." and you cna try other options as well. I know it's not ideal and seems like a weird timing issue, because it works on Wayland here as well. Hopefully we can get it fixed. https://www.freedesktop.org/software/systemd/man/logind.conf.html
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This is stil present for F39, could we bump the version please?
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I don't see the option, but this needs bumping to 41 :)
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.