Bug 364478 - Power settings concerning lid state are ignored / overridden
Summary: Power settings concerning lid state are ignored / overridden
Status: RESOLVED DUPLICATE of bug 366402
Alias: None
Product: Powerdevil
Classification: Plasma
Component: general (show other bugs)
Version: 5.6.4
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Development Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-19 00:00 UTC by Bzzz
Modified: 2016-08-06 12:51 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
dbus-monitor log at hibernation cycle (555.81 KB, text/plain)
2016-06-20 14:58 UTC, Bzzz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bzzz 2016-06-19 00:00:57 UTC
Having added the KDE PPA to fix the ultra-annoying dolphin bug #352207 of my Xenial installation, the system no longer obeys my "do not do anything" setting for closing the laptop lid. Instead, a very rapid suspend occurs. The "Energy Saving - KDE Control Module"* still shows my button event handling settings correctly and I also reset them and unticked the boxes one by one. However, this happens when closing the lid:

[865332.166732] systemd-logind[32415]: Lid closed.
[865332.168290] systemd-logind[32415]: Suspending...
[865332.623237] upstart: anacron main process (8568) killed by TERM signal
[865333.490806] PM: Syncing filesystems ... done.
[865333.558824] PM: Preparing system for sleep (mem)
[865333.559250] Freezing user space processes ... (elapsed 0.002 seconds) done.
[865333.562025] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[865333.563309] PM: Suspending system (mem)

...thanks a lot.
I expect my settings to be in effect OR a warning message if some other tool overwrites it. So even if this is not a bug in the specific KDE module, it is a bug in this very module not to check the validity of these settings.

*:How hard is it to give package information somewhere? Glad the help is broken too and says URL: help:/kcontrol/powerdevil/index.html and Additional Information: Unable to create io-slave: klauncher said: Error loading '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/help.so'.

Reproducible: Always

Steps to Reproduce:
1. Set up power config: Don't do anything when closing laptop lid
2. Close lid

Actual Results:  
3. Swear because suspend happens, downloads break, services are unavailable, etc

Expected Results:  
3. System stays up and running, geez, how hard can it be to do NOTHING?

I ticked "Major" because, well, if the power management system doesn't manage power, how much more broken can it be? Yes, emergency shutdown at low power still works, which is the only thing that keeps it from "Grave" status.

And: Leaving the machine running open unattended isn't an option. Annoying at night, dangerous if you got pets.
Comment 1 Kai Uwe Broulik 2016-06-19 06:33:44 UTC
Yay, logind futzing around with power management again... PowerDevil tells logind to leave it alone but apparently it doesn't care. What logind version is that? Can you run kded5 from console and see if you spot anything unusual in "PowerDevil" debug? Also, can you check on DBus for whether there's a PowerDevil inhibition on login1 manager (sorry, don't know the exact command for that right now)
Comment 2 Bzzz 2016-06-20 14:56:20 UTC
Well, it would be very helpful for a non-dev person to have something to check on. "logind" isn't a separate package to examine, not a single executable, doesn't have a manpage, synaptic doesn't find anything with logind in it, etc. 
systemd-logind as in the bug report also doesn't really pop up as executable as well. So here's the locate output:

locate logind
/etc/systemd/logind.conf
/lib/systemd/systemd-logind
/lib/systemd/system/systemd-logind.service
/lib/systemd/system/multi-user.target.wants/systemd-logind.service
/usr/lib/libreoffice/share/config/soffice.cfg/uui/ui/logindialog.ui
/usr/share/man/man5/logind.conf.5.gz
/usr/share/man/man5/logind.conf.d.5.gz
/usr/share/man/man8/systemd-logind.8.gz
/usr/share/man/man8/systemd-logind.service.8.gz
/var/log/upstart/systemd-logind.log.1.gz
/var/log/upstart/systemd-logind.log.2.gz
/var/log/upstart/systemd-logind.log.3.gz
/var/log/upstart/systemd-logind.log.4.gz
/var/log/upstart/systemd-logind.log.5.gz
/var/log/upstart/systemd-logind.log.6.gz
/var/log/upstart/systemd-logind.log.7.gz

The gzipped log files are pretty empty (350B max @ 14d uptime and some more power cycles) and especially without timestamps. 

I can however give the apt-show-versions systemd:
systemd:amd64/xenial-updates 229-4ubuntu6 uptodate
systemd:i386 not installed

kded5 run from console:
16:24:08:~$ kded5 
16:24:08:~$ 

Nothing else shows after closing and re-opening the lid.

I'll add an dbus-monitor dump from such a cycle as well. 

That aside: Doing a manual hibernation now doesn't work, instead the screen lock applies and after unlocking a "Hey, someone else is logged in, now hibernating does require root permission" popup is there. No other tty or graphic session is active, though. All results from ps axo user |  sort -u are system accounts plus this one that I'm using right now. So hibernating is actually broken twice: It does when it shouldn't, and it doesn't when it should.
Comment 3 Bzzz 2016-06-20 14:58:35 UTC
Created attachment 99627 [details]
dbus-monitor log at hibernation cycle

from running "dbus-monitor > logmebabyonemoretime.txt" while closing the laptop lid, opening again, unlocking the screen
Comment 4 Nicola Mori 2016-08-06 12:39:03 UTC
I noticed the same problem on my laptop. The settings are ignored and when the laptop is closed the system is always suspended, but in one case: if I set "Do nothing" for both "On AC Power" and "On Battery" profiles then nothing is actually done. But if I change just one of the two profile settings to any value then the laptop is suspended.
Comment 5 Nicola Mori 2016-08-06 12:48:21 UTC
Forgot to add details about my system: ArchLinux with Plasma 5.7.3 and systemd 231.
Comment 6 Bhushan Shah 2016-08-06 12:51:41 UTC
See linked bug report.

*** This bug has been marked as a duplicate of bug 366402 ***