Until kubuntu 13.04 Beta 1, power management worked well on my Lenovo ThinkPad L420, and according to the settings in KDE. Now with kubuntu 13.04 final, the system does not go to standby or hibernate after the specified timeouts for AC power, battery and low battery in the KDE system settings. Putting the system manually in standby or hibernate works fine from the K-Menu entries, and also closing the lid triggers the configured action. Letting the system run idle however never does. Pushing the power button causes the system to shut down and suspend at the same time: It first suspends and when resuming, it shuts down. Reproducible: Always Steps to Reproduce: 1. Configure timeouts for suspend/hibernate in system settings or use defaults 2. Wait for the timeout to pass Actual Results: System does not suspend/hibernate as configured in the systemsettings Expected Results: System should suspend or hibernate Manual suspend/hibernate from the K-Menu works fine.
Can you add "kded" (not "7020 kded4": logout and in if it doesn't appear) in kdebugdialog (and logout/in again). Then attach the output of 'tail -f .xsession-errors' when you leave the system for the idle time. The powerbutton issue you describe could be https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1124149
I did what you suggest and got the below output: kded(23135)/kio (Slave) KIO::Slave::kill: killing slave pid 23173 ( "trash://" ) kio_trash(23173)/kio (kioslave) KIO::SlaveBase::dispatchLoop: slave was killed, returning homerun(23186)/kio (Slave) KIO::Slave::kill: killing slave pid 23193 ( "trash://" ) kio_trash(23193)/kio (kioslave) KIO::SlaveBase::dispatchLoop: slave was killed, returning plasma-desktop(23182)/kio (Slave) KIO::Slave::kill: killing slave pid 23283 ( "thumbnail://" ) kio_thumbnail(23283)/kio (kioslave) KIO::SlaveBase::dispatchLoop: slave was killed, returning krunner(23245)/kio (Slave) KIO::Slave::kill: killing slave pid 23369 ( "trash://" ) kio_trash(23369)/kio (kioslave) KIO::SlaveBase::dispatchLoop: slave was killed, returning kded(23135) PowerDevil::PolicyAgent::requirePolicyCheck: Can't contact systemd kded(23135) PowerDevil::Action::trigger: Unsatisfied policies, the action has been aborted plasma-desktop(23182)/kio (Slave) KIO::Slave::kill: killing slave pid 23231 ( "file://" ) plasma-desktop(23182)/kio (Slave) KIO::Slave::kill: killing slave pid 23258 ( "file://" ) kio_file(23258)/kio (kioslave) KIO::SlaveBase::dispatchLoop: slave was killed, returning kio_file(23231)/kio (kioslave) KIO::SlaveBase::dispatchLoop: slave was killed, returning kio_file(23231) kdemain: Done kio_file(23258) kdemain: Done kded(23135) AutoAway::backFromIdle:
And yes, the powerbutton issue is exactly the bug you mentioned. Thanks!
Probably some application is inhibiting suspend. Check with "grep Inhibition ~/.xsession-errors" and paste it here. An addInhibition() call without a matching releaseInhibition() call would point to the culprit.
Very interesting. I am using an external screen with my laptop. When I connect it: kded(1986) RandrMonitorModule::checkInhibition: Active monitor list kded(1986) RandrMonitorModule::checkInhibition: ("LVDS1", "HDMI1") kded(1986) PowerDevil::PolicyAgent::AddInhibition: DBus service ":1.3" is requesting inhibition kded(1986) PowerDevil::PolicyAgent::AddInhibition: Added inhibition with cookie 2 from "kded" with "" kded(1986) PowerDevil::PolicyAgent::addInhibitionTypeHelper: Added interrupt session kded(1986) RandrMonitorModule::checkInhibition: Inhibing: 2 The system does not suspend/hibernate. When I disconnect the external screen: kded(1986) RandrMonitorModule::checkInhibition: Active monitor list kded(1986) RandrMonitorModule::checkInhibition: ("LVDS1") kded(1986) RandrMonitorModule::checkInhibition: Stopping: 1 kded(1986) PowerDevil::PolicyAgent::ReleaseInhibition: Released inhibition with cookie 1 Then the system does suspend/hibernate, and gives the following strange log: kded(1986) PowerDevil::PolicyAgent::setupSystemdInhibition: fd passing available: true kded(1986) PowerDevil::PolicyAgent::setupSystemdInhibition: failed to inhibit systemd powersave handling Why "failed to inhibit"? What I am really wondering about is why powersave handling should be inhibited when an external screen is connected. To avoid issues on resume? In fact, I sometimes had issues on resume with 12.10 with the external screen connected, so has the inhibition been added in 13.04 on purpose? Can I change this? I would like my system to save power also when an external screen is connected.
That's supposed to be a feature, lots of people like that so for example they can watch a movie with the laptop lid closed and things of the like. Will take a decision what to do with this for 4.11 :/ either leave it enabled or disable it.
Doing nothing when closing the lid with an external screen connected kinda makes sense to me, but I would still expect my system to suspend when I don't use it for a certain period of time. I wonder about the rules - shouldn't the system consider playing a video as activity not to be interrupted by PM? Or should the video player handle that, like some disable the screensaver? Could this be configurable? Someone watching a video can (temporarily) disable PM but someone using an external screen has no choice and needs to do manual PM.
Actually, the system *does* suspend when closing the lid, also with an external screen connected. Only the timeouts are ignored.
Is this the same bug as: Bug 268149 - KDE does not hibernate/suspend/shutdown when battery is critical low Because this is my problem. My Acer laptop with 64 bit 13.04 just runs the battery dry - it does not hibernate when it reaches the critical battery level...
Do you have an external screen connected? I am asking because the timeouts work for me on a Lenovo L420. But they are still ignored when an external screen is connected. And I still don't see what one thing has to do with the other; an external screen connected does not imply a user is watching a movie, and even if, it does not mean PM should be disabled and energy and hardware can be wasted.
@Torsten No, no external screen is attached.
Any development on this issue? Kubuntu 13.10 still ignores power management timeouts and does not go to standby/suspend when an external screen is connected. And I still think this is unexpected and possibly causes a waste of energy.
Another issue with this: The prohibited standby "event" seems to remain in some queue of pm events, since pushing the power button which just shuts down the system as of bug https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1201180 then actually causes the system to go to standby. Another push of the power button shuts down the system instead of resuming it. After a restart the behaviour of the power button is again just shut down.
This bug is reported on libsolid which is the kdelibs4 version of the solid library. It is now in maintenance mode. If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid or Powerdevil.
I can confirm this problem for Kubuntu 14.04. Since it seems that this problem won't get fixed I wrote a small cronjob as workaround (only tested on Kubuntu 14.04): The bash script (to be put e.g. in /usr/local/bin/suspend.sh: #!/bin/bash POWER_PERCENT=`cat /sys/class/power_supply/BAT0/uevent | grep POWER_SUPPLY_CAPACITY= | sed 's/POWER_SUPPLY_CAPACITY=//'` STATUS=`cat /sys/class/power_supply/BAT0/uevent | grep POWER_SUPPLY_STATUS= | sed 's/POWER_SUPPLY_STATUS=//'` echo "${STATUS}: ${POWER_PERCENT}%" if [ $STATUS != 'Discharging' ]; then echo "Not discharging - no action"; exit; fi if [ $POWER_PERCENT -le 10 ]; then echo "Discharging & critical power: suspending..."; pm-suspend; fi And the cron entry, e.g. in the file /etc/cron.d/suspend (which must be executable!): SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin * * * * * root /usr/local/bin/suspend.sh
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!