My system worked fine. Then I updated all packages through YaST’s software tool, as I usually do after a couple of months.
Problem: The laptop suspends if the lid remains unchanged, but closed.
Before the update, the laptop would only suspend if the lid changed from open to closed. Now it always suspends if the lid is closed, regardless of whether the lid was closed before.
Background:
I use my laptop with several docking stations. In the main docking station, I only use two external monitors, while the laptop is docked with a closed lid. I dock with the laptop being powered down. I power up the laptop with the lid being closed the entire time. I have this setup since several years and used it for most workdays throughout the year without a problem.
Now the laptop goes quickly to sleep after I log in in this configuration. I can restart by pressing the power button, but the laptop quickly goes to sleep again. The lid remains closed the entire time. If I open the lid, the laptop remains awake, but then I have to disable the laptop’s internal display, which causes other problems, as I use docking stations with one external display where the internal display is used alongside.
Thanks for any suggestions on how to restore the original behaviour.
I am on Leap42.1 with KDE.
Note that the lid switch is ignored if the system is inserted in a docking station, or if more than one display is connected.
I suspect that what needs to be done, is in the KDE Plasma 5 System Settings, Power Management category, Energy Saving module, the “Button events handling” needs to be set to “When laptop lid closed” –>> “Do nothing” (“Even when an external monitor is connected”).
It gets worse: Leap 42.1 has “LidSwitchIgnoreInhibited=” and “PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited= and HibernateKeyIgnoreInhibited= default to “off”. LidSwitchIgnoreInhibited= defaults to “yes”. This means that the lid switch does not respect suspend blockers by default, but the power and sleep keys do.”; Leap 42.2 RC2 has something totally different.
My bets are still with KDE Plasma 5 PowerDevil – I suspect that, the KDE PowerDevil folks haven’t (yet) considered the case of Laptops which use Docking Stations . . .
No, that’s wrong. LidSwitchIgnoreInhibited=yes should not inhibit (KDE’s e.g.) suspend blockers (inhibitions). This was a bug in the previous systemd update.
The latest one restored the old state in this regard.
See also: 1001790 – kde "suspend when lid is closed" settings are ignored
And the default settings have not been changed at all.
My bets are still with KDE Plasma 5 PowerDevil -- I suspect that, the KDE PowerDevil folks haven't (yet) considered the case of Laptops which use Docking Stations . . .
Nonsense. Especially if it worked as expected before (there hasn’t been any update to KDE or powerdevil recently)
Must be related to the systemd update I suppose.
PS: apparently that latest systemd update has not been released for 42.1 yet (I got it on 13.2 yesterday…).
Should be there in the next days then, I suppose…
Reading the openSUSE and GitHub bug reports, it seems that the man page text has never reflected what SHOULD happen and, it caused an unnecessary code change which had to be reverted – commit date of the reverted code: 2016-08-08. Hopefully this time around the systemd folks will correct the man page text to remove the confusion.
It hit Leap 42.2 RC2 this morning and is presumably therefore also in the Leap 42.2 production release which occurred a couple of hours ago.
I’ll check my Leap 42.1 system before applying the Leap 42.2 update later today.
Changing the KDE settings did not change the behaviour: I have checked the KDE Powermodul and the settings are “ticked checkbox for what do to when the lid is closed with selection to <do nothing>” and also checked “even when an external monitor is connected”.
…so everything is set to default. I did not try to change anything here, as I do want the lid switch to have an effect when an opened lid is closed - i just don’t want any action if the lid remains closed all the time?
Yes.
Unfortunately that wrong behavior change made it into the systemd 231 release, and got backported to all supported openSUSE releases too.
Hopefully this time around the systemd folks will correct the man page text to remove the confusion.
Yes they have, and that has been included in the latest update too:
* Mon Oct 24 2016 fbui@suse.com
- Import commit
2ad9feb man: explain that *KeyIgnoreInhibited only apply to a subset of locks
60ac1f8 Revert "logind: really handle *KeyIgnoreInhibited options in logind.conf" (bsc#1001790 bsc#1005404)
It hit Leap 42.2 RC2 this morning and is presumably therefore also in the Leap 42.2 production release which occurred a couple of hours ago.
I’ll check my Leap 42.1 system before applying the Leap 42.2 update later today.
Yes, the systemd followup update did still make it into 42.2 final apparently.
Yes, that’s exactly what that bug is about:
systemd ignores KDE’s lidswitch inhibition, and handles the lidswitch itself (without respecting KDE’s settings of course).
You can “fix” it by setting “LidSwitchIgnoreInhibited=no” in logind.conf (then KDE should be able to take over), or just wait for the update to be released which will hopefully be in the next days.
Now on my Leap 42.1 system – and no, the patch hasn’t appeared here yet.
I have checked the Leap 42.2 RC2 (in a VM) again and, no (my mistake) the systemd patch didn’t hit 42.2 RC2 this morning. :shame:
I’m about to upgrade this system – will check the released 42.2 once the update has completed.
There is no RC2 available any more, the repos contain 42.2 final (including this fix) since about a week already.
Actually according to OBS the latest systemd update has been accepted to 42.2 17 days ago, and is in the repos since then.
I too have suffered this particular problem and after hunting around the Net was unable to find a satisfactory solution. So I have reverted to a previous version of systemd, which is the “cause” of this issue.
In Yast -> software management.
Search for systemd.
Highlight the systemd package. (On my box it is just “systemd”)
In the lower part of the screen - choose “Versions”.
Scroll down until you find the version you need (I did not know which version was the last working, so I tried the oldest (which required the DVD) then I tried the next one up. 210-86.1 I clicked on it and then clicked on Accept.
The problem was gone. There might be other ramifications but the machine now works (Lenovo T420 otherwise up to date on patches).
