Bug 1615

Tagging as a regression as one user seems to recall this working in the past.

Bumping to Major because I added the report to the R14 etherpad road map.

It's working here, both under Mageia 2 and CentOS6 .
If I Right-click on Tdepowersave icon, then choose "suspend to ram", my computer suspends to ram ...

(En réponse au commentaire 3)
> It's working here, both under Mageia 2 and CentOS6 .
> If I Right-click on Tdepowersave icon, then choose "suspend to ram", my
> computer suspends to ram ...

Sorry I misunderstood the problem I think.
Can you precise exactly in which circunstance the Suspend to ram fails ???

As I mentioned in the original report, I can suspend using the popup menu. I cannot suspend/sleep using the app's configuration options. When the timeout occurs, I will see a countdown dialog, the screen saver activates, but the laptop does not suspend/sleep. The moment I touch the keyboard, the laptop suspends, which is backwards.

OK I've found it, the feature is called "autosuspend" (I was looking for a "programmatically" option or something in the GUI).

I've tried checking it, set action "Suspend to ram" and delay to 1 minute.
After 1 minute idle, I have a popup with 30 second countdown.

(BTW, I would prefer that the popup vanish on any mouse or keyboard event, not the obligation to move the cursor over the "cancel" button and then click it)

After the 30 seconds counter, my computer (Mageia 3) suspends to ram as expected...

Doesn't work here, as I previously described. I can understand never suspending being a bug, but when I touch the keyboard or move the mouse I also expect the screen saver to simply disappear and nothing else happen. Yet that moment is when the laptop finally suspends. Not to mention tdepowersave suspends just fine from the popup menu.

Would you please post your tdepowersaverc file? I'll test with that rc file because suspend works for you after 1 minute.

Yes, any user action such as keyboard or mouse movement should make the 30 second count down dialog disappear automatically for the simple reason the timeout to suspend has already terminated by user action.

I updated the bug report summary to use the word autosuspend.

Created attachment 1458 [details]
tdepowersaverc from MGA3, suspend to ram 1 minute

I tested the rc file. No change, but I noticed some peculiarities.

* If the user's home directory is from an NFS share, tdepowersave starts to suspend and then gets locked into some kind of loop. On my Thinkpad T400, there is a quarter-moon symbol LED to note when the laptop is in suspend-to-ram. The LED keeps blinking during this lockup loop. I cannot recover from this loop. Nothing returns the desktop screen. Pretty much I have to power down the laptop.

* There seems to be pecking order to how tdepowersave behaves. When I had the screensaver and autodimm options set, tdepowersave never tried to suspend to ram. When I disabled those options then I finally saw the 30 second countdown dialog. My initial thinking is the screensaver settings and autodimm settings must be configured to a shorter duration than the suspend setting. That is, either screensaver and autodimm are disabled or those events occur before the suspend event. Seems to me that tdepowersave should simply invoke whatever option when any respective configuration times out, regardless of any order.

* During one test, tdepowersave announced going into suspend with the dialog, then after 30 seconds I saw the dbus popup notification, then nothing. I had no access to the desktop, nothing worked. I used Ctrl-Alt-Backspace to recover.

* During one failed episode when I used Ctrl-Alt-Backspace to terminate some kind of loop, I noticed the following in my xsession-error log:

hal-find-by-property: command not found

I don't have hal installed on this system and tdepowersave is supposed to be for hal-less systems. The older kpowersave is for hal systems.

* During some of the failure episodes I see many systemdirnotify messages. Those messages are from commit d41f5217 2012-05-15, where we added a basic stdout printf message as a means to avoid a possible race condition. This would seem to confirm my description where tdepowersave sometimes locks into an unrecoverable loop.

Summary: I cannot yet replicate either the failures or successes with consistency. I really don't know why tdepowersave is so wacky on my laptop.

I again tested tdepowersave. The laptop never fully executes suspend. The screen saver starts --- why I don't know, the quarter-moon LED on the laptop starts blinking, then the laptop gets stuck in a loop or race condition. I can't terminate the screen saver, I can't toggle to alternate consoles (Ctrl-Alt-F[1-6]), and Ctrl-Alt-Backspace will not terminate X.

I see the following in xessions-errors:

[FIXME] HardwareInfo::setPowerSave unimplemented!

The only cure is powering off the laptop.

My tdepowersaverc:

[General]
ActionOnPowerButton=LOGOUT_DIALOG
ActionOnS2DiskButton=
AlreadyStarted=true
Autostart=false
AutostartNeverAsk=true

[Notification Messages]
systemtrayquitTDEPowersave=false

[Powersave]
autoDimm=false
autoDimmSchemeBlacklistEnabled=false
autoInactiveAction=Suspend to RAM
autoInactiveActionAfter=1
autoSuspend=true
disableNotifications=false
specPMSettings=false
specSsSettings=false

Looks like part of the problem might be permissions or policies. When logged in as root then tdepowersave will autosuspend.

Oddly, once and only once. As root I can repeatedly manually suspend using the popup menu, but when autosuspend triggers the first time autosuspend no longer triggers thereafter.

I can manually suspend with the popup menu as non-root.

I don't know how tdepowersave triggers or what backend permissions or policies are needed. Any light shed in this direction will help me debug. I do have consolekit and polkitd running.

Nope. Looks like manual suspend from the popup menu no longer works as non-root. Same lock-up.

When this start-to-suspend-but-never-finish lockup occurs, I can't ssh or ping into the laptop. So the suspend process proceeds at least to that point. Yet the screen saver remains active and nothing else happens. The power button is the only remedy.

I think I finally understand the confusion.

When the user's $HOME is through an NFS share, tdepowersave goes beserk, into some kind of endless loop or race condition. I don't know why tdepowersave should behave so nasty with an NFS share.

When using a local $HOME, both root abd a non-root users can autosuspend once and only once. Both root and non-root users can repeatedly manually suspend through the popup menu.

Regarding the "hal-find-by-property: command not found" messages, I traced that to tdebase/kdesktop/lock/lockprocess.cc:2405. As I am using a non-hal system, I'll find a new report against that.

I am updating this bug report summary and filing a new report against the NFS behavior.

Regarding the NFS problem, I wonder if tdepowersave is attempting to update a file in the $HOME directory (e.g. some kind of configuration file in ~/.trinity) after the suspend process has already been initiated.  However, this appears to be a corner case, as suspending from ANY running desktop environment with an active NFS $HOME mount is poorly handled at best and completely unsupported at worst.  See for example http://www.devheads.net/linux/fedora/user/suspend-ram-and-nfs-home.htm-0  Root is "special", suspending directly via a system power device node, and therefore may not run the same network unmount scripts that a normal user would be running via the DBUS power management service.

Given that, I wonder if it makes more sense to detect a network $HOME mount and refuse suspend/hibernate?

>Given that, I wonder if it makes more sense to detect a network $HOME mount and
>refuse suspend/hibernate?
I envision enterprise users on the road who connect back to the home network and use a network home share. Such users still want to conserve energy usage.

After surfing the web I agree the culprit is NFS.

The system can't unmount the non root user's $HOME because the mount point is active. So perhaps the Suspend to Disk and Suspend to RAM options should be ghosted when /home is an NFS share. Or CIFS too. Or better, if /home is not a local mount, then disable those options. Seems like a cruddy work-around. :-(

(In reply to comment #15)
> Or better, if /home is not a
> local mount, then disable those options. Seems like a cruddy work-around. :-(

Yep, I agree.  Unfortunately this looks like a limitation of the current Linux network mount design, and therefore is not something that can be fixed at the level of a desktop environment.

Tim

Lockout code added in GIT hash 9d76cb9 (tdelibs); tdepowersave should now refuse to suspend/hibernate if $HOME is mounted on a network file system.

The titular issue was resolved in the process of fixing Bug 1597.

Looks like the patches are working. With a local /home the popup menu options are available and function as expected and described in previous comments. Autosuspend also functions correctly.

When /home is remote, the popup menu options are disabled. There are no autosuspend options, but my mind was prepared to see the entire autosuspend dialog disabled rather than empty drop-down lists. I think disabling the "Enable autosuspend" check box makes more sense.

I agree with Francois the autosuspend dialog is a tad silly. Although the dialog has a Cancel button, any mouse or keyboard action should automatically stop the autosuspend process and close the dialog. Not a killer but would be nice.

I just noticed that despite the autosuspend options not appearing in the autosuspend options drop-down list, when the "Enable autosuspend" check box is enabled TDEPowersave nonetheless attempts to autosuspend and invokes the 30 second countdown dialog. This was with a remote /home.

(In reply to comment #19)
> I agree with Francois the autosuspend dialog is a tad silly. Although the
> dialog has a Cancel button, any mouse or keyboard action should automatically
> stop the autosuspend process and close the dialog. Not a killer but would be
> nice.

Can you open a separate enhancement report for this?  While it may seem simple on the surface, X11 doesn't make monitoring all input devices for activity easy.

Also, the text of the dialog would need to be modified so that the user is aware of the fact that touching the mouse will kill both the dialog and suspend/hibernate request.

I am still not convinced that this would be a good idea from a usability perspective.  I am, however, open to further explanation in the new report. :-)

(In reply to comment #20)
> I just noticed that despite the autosuspend options not appearing in the
> autosuspend options drop-down list, when the "Enable autosuspend" check box is
> enabled TDEPowersave nonetheless attempts to autosuspend and invokes the 30
> second countdown dialog. This was with a remote /home.

Sounds like tdepowersave doesn't check for suspend/hibernate functionality before starting the associated timers.  The TDE HW library will still block the request AFAIK, but this is a definite usability issue.

The original problem report of autosuspending only once seems resolved --- as long as /home is local.

Goofy things happen when /home is remote. The autosuspend dialog appears, times out at 30 seconds, and then I see two system tray popup notifications. One that autosuspend will begin and another that autosuspend is disabled by the administrator. The machine never autosuspends, of course.

That latter notification is not technically correct. Autosuspend is disabled because /home is remote.

Unlike a local /home, the autosuspend again runs only once. Oddly, when I manually cancel the dialog, most of the time autosuspend will try again at the next interval. When I let the autosuspend dialog time out at 30 seconds, then autosuspend does not repeat.

As the original patches are to disable suspend when /home is remote, perhaps the best followup is 1), disable the entire autosuspend config dialog and 2) ensure the dialog popup never appears. If the popup dialog never appears then the system tray notifications should never appear as well.

(In reply to comment #20)
> I just noticed that despite the autosuspend options not appearing in the
> autosuspend options drop-down list, when the "Enable autosuspend" check box is
> enabled TDEPowersave nonetheless attempts to autosuspend and invokes the 30
> second countdown dialog. This was with a remote /home.

This *should* be fixed in GIT hash ba6b207.  I was unable to test due to the recent library version changes affecting my development machine (need time to sort it out); if you can verify the fix works as intended we can close this report.

Thanks!

Seems autosuspend is now disabled when /home is remote.

Autosuspend repeats more than once when /home is local.

Is there a way to inform the user when suspend is disabled when /home is remote? Perhaps when the user clicks the system tray icon to open the Information Dialog? Perhaps a line in the Miscellaneous section, something like this:

...
TDE hardare subsystem               active
Suspend                             disabled
  (Disabled when /home is remote)

I'll keep this open for a few days more to test more thoroughly.

(In reply to comment #24)
> Seems autosuspend is now disabled when /home is remote.
> 
> Autosuspend repeats more than once when /home is local.
> 
> Is there a way to inform the user when suspend is disabled when /home is
> remote? Perhaps when the user clicks the system tray icon to open the
> Information Dialog? Perhaps a line in the Miscellaneous section, something like
> this:
> 
> ...
> TDE hardare subsystem               active
> Suspend                             disabled
>   (Disabled when /home is remote)
> 
> I'll keep this open for a few days more to test more thoroughly.

Sounds like the TDE HW library needs to provide a reason code if sleep, suspend, and/or hibernate are disabled.  Now is the time to fix this due to the already scheduled rebuilds--I'll see what I can do.

I don't know how this is related, but this morning on my laptop I see dozens of the following messages in my xsession-error log:

tdepowersave: WARNING: Couldn't request charge_level.unit for udi: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/

The following tdepowersave messages also appear in the xsession-error log:

* tdepowersave: WARNING: Unknown error while acquire org.freedesktop.Policy.Power interface

* [FIXME] Hardware::setPowersave: unimplemented!

I am closing the report as resolved.

As mentioned in comment 24, there should be a way to inform the user why sleep support is disabled when the user's /home is remote. Better, as noted in bug report 1623, the KDE4 Powerdevil uses UPower, does not have problems with remote /home, and we should uses those methods in TDEPowersave. Those problems can be addressed in bug report 1623, which directly addresses the remote problem. I copied those respective comments to bug report 1623.

Regarding the warning messages in comments 26 and 27, those are being addressed in bug report 1655.