I wonder if anyone have seen it. Sporadically GNOME session starts to ignore lid close. I cannot so far find any pattern here. It will suspend just find with pm-suspend, so it is only GNOME part that gets stuck.
Any pointers how I can debug it? I am not that deep in GNOME internals.
This is pretty much standard 64 bit system with all current (applicable) updates but without any third-party software except flash or non-standard GNOME shell extensions.
I’m not a Gnome user, but anything unusual reported /var/log/pm-suspend.log when suspend fails?
This is likely to be hardware specific and/or maybe kernel-related, so maybe your CPU and graphics hardware may come in to play. It might pay to share this info here.
I wanted to share this Ubuntu thread, not because it is directly applicable, but because it might give you some ideas for likely causes and investigating further…
Examine the kernel ‘dmesg’ output upon unsuccessful suspends too.
E-h-h … suspend does not *fail. *Suspend does not even start. As I said, pm-suspend at this point suspends just fine.
This is likely to be hardware specific and/or maybe kernel-related
That’s possible. But I forgot the major third-party part - nVidia driver. 
IIRC current X11 driver fiddles with input events. It may be possible that it “eats” them away.
I guess you could try configuring Gnome not to suspend on lid closure. Then run
upower --monitor-detail
and then close/open lid repetitively to see if the event is captured consistently like this
# upower --monitor-detail
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[21:55:57.155] daemon changed:
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: yes
on-low-battery: no
lid-is-closed: yes
lid-is-present: yes
is-docked: no
[21:55:57.281] daemon changed:
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: yes
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
[21:55:58.999] daemon changed:
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: yes
on-low-battery: no
lid-is-closed: yes
lid-is-present: yes
is-docked: no
[21:55:59.125] daemon changed:
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: yes
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
But I forgot the major third-party part - nVidia driver.
I doubt it.
What model laptop?
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[14:11:41.180] daemon changed:
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: yes
lid-is-present: yes
is-docked: no
[14:11:47.649] daemon changed:
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
Dell XPS M1330
FYI -
I’ve been seeing the same thing running 12.2/KDE.
I don’t automatically suspend by closing the lid, but manually select the suspend option from a menu (available a number of different ways).
I’ve observed after suspending a number of times usually over 2-3 days of heavy use, the suspend button just disappears. Like you say, pm-suspend works just fine if I choose to do so, but that doesn’t shutdown the desktop gracefully, you’re essentially crashing the Desktop, maybe your open apps might survive, maybe not . Seems it also happens most often if I have FF open, other apps seem to be less likely related to this issue.
So,
I’ve been speculating that FF does not suspend well, and so I close it whenever I can (but of course may be a prime reason why I’m suspending and not shutting down). Unfortunately for me, using a different browser is not practical, FF is my workhorse browser.
I also recommend you look to see whether the suspend button is also disappearing in your case and if your problems might also circumstantially be related to FF(which might ultimately prove not to be related).
If this is actually a common occurrence, then I suppose a bug should be submitted.
HTH,
TSU
I can’t say I’ve noticed this behaviour - I frequently suspend by the menu option, and have all kinds of applications including FF open as it is a work computer. I do shut down from time to time, with maybe 5-10 suspend/resume cycles in between typically. I’ll thrash my system over the next few days, to see whether I can replicate what you’re experiencing. It probably comes down to the hardware one is using I suspect.
My computer recently stopped suspending. Then I realized that I need to unplug my external hard drive (since it’s powered by the computer).
Probably your issue is different, but thought I’d mention this just in case. 
I also noticed this erratic behavior after upgrading a notebook RAM from 2GB to 8GB but keeping the swap at the original 2GB.
After reformatting the swap partition to 8GB this hasn’t happened yet, but I only suspended a few of times - this is just a backup lappy.
Running oS 12.1 64 bit, fusion chipset (AMD) running the proprietary video driver fglrx.
Also a bit weird, as S2R shouldn’t use swap, or am I mixing things?
Swap is only used for suspend-to-disk (hibernation) in this context.
I have Suspend in GNOME menu, but it does nothing - it blanks screen and that’s all. Which returns us to the question - how to debug what happens inside GNOME session?
Yes, I mean suspend to RAM. Can I edit thread title? I do not see any option for it.
It probably comes down to the hardware one is using
Quite unlikely. Hardware works fine when it get chance to actually perform suspend.
Aha … now it is better. In ~/,xsession-errors:
(gnome-shell:14660): libupower-glib-WARNING **: Couldn't suspend: not authorized
(gnome-shell:14660): libupower-glib-WARNING **: Couldn't suspend: not authorized
JS ERROR: !!! Exception was: Error: Error invoking UPowerGlib.suspend_sync: not authorized
JS ERROR: !!! lineNumber = '0'
JS ERROR: !!! fileName = '"gjs_throw"'
JS ERROR: !!! stack = '"("Error invoking UPowerGlib.suspend_sync: not authorized")@gjs_throw:0
(null,[object Error])@/usr/share/gnome-shell/extensions/alternative-status-menu@gnome-shell-extensions.gcampax.github.com/extension.js:31
([object _private_Gio_DBusProxy],[object _private_Gio_SimpleAsyncResult])@/usr/share/gjs-1.0/overrides/Gio.js:87
"'
JS ERROR: !!! message = '"Error invoking UPowerGlib.suspend_sync: not authorized"'
And I just got authorization error when trying to install updates. So it all boils down to our beloved PolicyKit/ConsoleKit/whatever-kit-of-the-day 
ck-list-session does not show anything and in logs there are errors related to ConsoleKit since couple of days which correspond to the time when it stopped suspending. So apparently my session does not exist from the point of view of whatever instance is responsible for preforming suspend on GNOME shell command.
I lost track how all those *Kits works long ago. Every year they are replaced by new and shiny *Kit which is no more compatible to previous version, half of your programs use old *Kit, half of your programs use new *Kit, there is zero documentation how those *Kits work or relate to each other or how you can investigate what they do.
All of this is pretty frustrating. Really
ck-list-session does not show anything and in logs there are errors related to ConsoleKit since couple of days which correspond to the time when it stopped suspending. So apparently my session does not exist from the point of view of whatever instance is responsible for preforming suspend on GNOME shell command.
This looks like more than a suspend issue. If you’re getting xsession-errors like this with the Gnome shell, I’d recommend filing a bug report. It’s the only way it’ll get the attention required.
Just a few more ideas to look at…
Although I’ve noticed circumstantial symptoms using KDE, this might also apply to you…
I suspect suspend won’t complete because a process refuses to shutdown, causing suspend to hang. So, ever since this problem started happening, by process of elimination I’ve been tracking if specific open applications might be the problem by closing specific programs regularly. I’ve suspected FF on my system because browser add-ons can almost run without any restriction and running once removed(through a browser) might be a factor.
You may have better luck but I have not been able to identify culprits using top, htop, kmanager (on KDE), inspecting the system log (/var/log/messages).
I also wonder if how openSUSE itself goes into suspend might be faulty in concept and affected by my installation on SSD which means that reads may be happening a lot faster than expected. Sometimes the machine goes into susension instantly and I ask “How the heck can everything be suspended so fast?” Other times, the system goes into partial suspension which likely means that the system is obviously waiting for a process to be end gracefully. I’ve looked for evidence but haven’t seen conclusive proof that openSUSE has a max time limit before forcefully terminating running or hanging processes (there is in Windows).
If you’re noticing similar suspend issues despite using a different Desktop than me, although at this time I think it’s more a Desktop coding issue than the underlying OS, you may be looking at similar causes/possible solutions.
TSU
The OP was complaining of random failure to suspend with lid closing. I think a good place to to eliminate this trigger from other suspend issues would be to try something (as user) like
qdbus org.freedesktop.PowerManagement /org/kde/Solid/PowerManagement suspendToRam
If sporadic failure to suspend can be demonstrated here, then we know it is not related to lid closure events. FWIW, I have seen reports concerning laptops with magnetic (reed switch) type sensors which can fail intermittently.