Bug 1623

Although suspend has been disabled when /home is remote, I wonder whether we are missing something fundamental or obvious. The acpi daemon works just fine with remote connections, as witnessed when I use Fn-F4 or close the lid. Suspend to ram works without a hitch.

I realize we need to get R14 out the door soon, but let's leave this report open so we can review more thoroughly.

(In reply to comment #1)
> Although suspend has been disabled when /home is remote, I wonder whether we
> are missing something fundamental or obvious. The acpi daemon works just fine
> with remote connections, as witnessed when I use Fn-F4 or close the lid.
> Suspend to ram works without a hitch.
> 
> I realize we need to get R14 out the door soon, but let's leave this report
> open so we can review more thoroughly.

The ACPI daemon runs as root and is deprecated.  While I know some of the older methods work (sometimes at least!) with an NFS mounted $HOME, they will still break in many corner cases.  For example, what happens if acpid suspends the machine and the NFS server is not available on resume (network failure, server outage, etc.)?  A quick Google search indicates that the user has to forcibly power down the machine if anything goes wrong in reconnecting to the NFS server on resume--hardly something that we should encourage. ;-)

All that being said, if you can point me to a way to *reliably* make suspend and NFS work using the newer DBUS daemons (upower2, etc.), I will try to fix this report instead of simply locking out the suspend on NFS $HOME.

I'll look around --- I'm sure the devs with other desktop environments and utilities have run into the same problem.

Perhaps we need not look too hard. :-)

Powerdevil is the KDE4 heir to both klaptop and the former kpowersave. The online kcm screen shots I viewed look a lot like the old kpowersave and klaptop.

Powerdevil uses various backends, of which upower is supported.

Powerdevil runs as a KDED service and is part of the kde-workspace sources.

Seems we could browse the powerdevil sources for how to adapt tdepowersave to upower.

If after addressing other outstanding reports for R14.0.0 release and we have time to restore suspend functions with a remote /home, fine. If not then we can hit this in R14.0.1.

Resolving this bug report:

1. Adopt methods used in KDE4 Powerdevil and Upower to avoid disabling autosuspend when /home is remote.

2. If the previous remedy is impossible then provide the user information to know why autosuspend is disabled.

With respect to item 2, the following conversation is copied from bug report 1615, comments 24 and 25:

=======================

Comment 24:

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)

=======================

Comment 25:

> 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)

Sounds like the TDE HW library needs to provide a reason code if sleep,
suspend, and/or hibernate are disabled.

=======================

Created attachment 1574 [details]
Test patch for enabling autosuspend when $HOME is a network mount

This patch is for testing purposes only. Do not push this patch to git.

The patch restores the autosuspend function to the tdepowersave popup menu when $HOME is a network mount. This feature was disabled in commit 9d76cb94 2013-08-26.

I don't know whether the test patch is complete. There is another patch from commit ba6b2079 2013-08-29, but I don't think that reversing that patch is necessary.

I did not need to rebuild tdepowersave after rebuilding tdelibs with the test patch.

The question was raised in the dev mail list whether commit cbbc7ad0 might help resolve the problem reported in this bug report. After rebuilding tdelibs with the test patch, commit cbbc7ad0 does not resolve the problem of trying to suspend to ram when $HOME is a network mount.

I did not rebuild tdepowersave, only tdelibs.

When selecting the suspend to ram option from the tdepowersave popup menu, the screensaver starts but the system then becomes unusable. That is, the laptop never suspends to ram and there is no way to stop the screensaver. Toggling to a different console (Ctrl-Alt-Fx) also is not possible, almost as though the system was in a partial suspend. I had to power off the laptop to recover. I did not try ssh to recover.

Darrell, is this still happening?

I have not checked in a while, but the last time I tested, not too long ago, the bug still exists.

Testing requires rebuilding tdelibs and tdepowersave with commit 9d76cb9 reversed. That commit has to be reversed to re-enable the suspend option.

I rebuilt tdelibs with a reversed commit 9d76cb9 to re-enable the Suspend to RAM option.

This bug still exists and is still nasty. The entire system becomes unresponsive. Even a previously open console stopped working.

I booted the system into run level 3 (command line). I logged in as root in console 6. I then logged as non-root in console 1 and started X with startx. The non-root account is through an NFS share. After Trinity started and settled I started tdepowersave. From the popup menu I selected Suspend to RAM.

The suspend process started but quickly hung. While I could toggle to console 6 (Ctrl+Alt+F6), there was nothing but a blank screen and a blinking cursor in the upper left corner. Pressing Ctrl+Alt+Del while at console 6 did nothing. I had to power off the system manually.

Without reversing commit 9d76cb9 the Suspend options in the popup menu are disabled. There is no explanation to the user why the options are disabled. Disabling the options effectively avoids the problem but does not resolve the problem.

To reverse commit 9d76cb9, use the attached test patch. The patch is for testing only to restore the popup menu options.

I just tried this as a normal user on my Debian Jessie system with the latest GIT sources and the tdelibs lockout disabled.  Suspend worked perfectly whether just $HOME/.trinity was NFS mounted or the entire $HOME directory was NFS mounted.

The only possible difference that springs to mind is that I compile without enabling NDEBUG.  It is theoretically possible, though not all that likely, that one of the debug messages prints to ~/.xsession-errors after the $HOME share is disabled, causing a hang.  However that hang is not so much a TDE bug as a kernel and/or system bug.

Can you test again?  You don't have to rebuild/reinstall tdepowersave to reenable suspend, only ./tdelibs/tdecore.

Thanks!

>Suspend worked perfectly whether just $HOME/.trinity was NFS mounted or the
>entire $HOME directory was NFS mounted.
Are you using tdepowersave to manually suspend or using the keyboard or laptop lid to manually suspend? As stated in my original report, I have no problems suspending with the keyboard or laptop lid.

In a previous commit you disabled/ghosted the manual suspend option in tdepowersave when /home is a remote mount (comment 6).

I have been compiling tdelibs with the attached test patch that reverses the commit that disables the suspend option in tdepowersave. I have been compiling and running that way for a long time, probably since I attached the test patch.

That said, I just tested tdepowersave (using the attached test patch). Unlike my last post (comment 10) I now can manually suspend with an NFS /home using tdepowersave. I tested several times in a row.

I reconfigured tdepowersave to autosuspend after 1 minute. The laptop suspended without incident. I tested several times.

All fascinating since my last post.

As I have not built tdelibs without the test patch in more than a year, I need to rebuild tedelibs without the test patch. But to return to the beginning, if I rebuild tdelibs without the test patch, is manual suspend still disabled in tdepowersave when /home is remote?

(In reply to Darrell from comment #12)
> >Suspend worked perfectly whether just $HOME/.trinity was NFS mounted or the
> >entire $HOME directory was NFS mounted.
> Are you using tdepowersave to manually suspend or using the keyboard or
> laptop lid to manually suspend? As stated in my original report, I have no
> problems suspending with the keyboard or laptop lid.

Manual suspend from the popup menu; as mentioned in Comment 11 I reversed the lockout patch before testing.

> In a previous commit you disabled/ghosted the manual suspend option in
> tdepowersave when /home is a remote mount (comment 6).
> 
> I have been compiling tdelibs with the attached test patch that reverses the
> commit that disables the suspend option in tdepowersave. I have been
> compiling and running that way for a long time, probably since I attached
> the test patch.
> 
> That said, I just tested tdepowersave (using the attached test patch).
> Unlike my last post (comment 10) I now can manually suspend with an NFS
> /home using tdepowersave. I tested several times in a row.
> 
> I reconfigured tdepowersave to autosuspend after 1 minute. The laptop
> suspended without incident. I tested several times.
> 
> All fascinating since my last post.
> 
> As I have not built tdelibs without the test patch in more than a year, I
> need to rebuild tedelibs without the test patch. But to return to the
> beginning, if I rebuild tdelibs without the test patch, is manual suspend
> still disabled in tdepowersave when /home is remote?

Correct.  If you can confirm that suspend now works with an NFS-mounted $HOME I will disable the lockout in GIT.

There were changes over time to the DBUS calling system as well as the TDE hardware library.  In particular IIRC we got fed up with upower and now use our own daemon to suspend; this might be why it started working.

>Manual suspend from the popup menu; as mentioned in Comment 11 I reversed the 
>lockout patch before testing.
Did you use the attached patch? Asking only to validate we are using the same base.

>this might be why it started working.
I also moved from Slackware 14.0 to 14.1 after my last confirmation post about the bug. So who knows the resolving chain of events.

Starting to sound as though the tdelibs lock can be formally reversed and this bug report closed as resolved.

(In reply to Darrell from comment #14)
> >Manual suspend from the popup menu; as mentioned in Comment 11 I reversed the 
> >lockout patch before testing.
> Did you use the attached patch? Asking only to validate we are using the
> same base.

Most of it--I didn't bother commenting out the helper function, but otherwise identical, yes.

> >this might be why it started working.
> I also moved from Slackware 14.0 to 14.1 after my last confirmation post
> about the bug. So who knows the resolving chain of events.
> 
> Starting to sound as though the tdelibs lock can be formally reversed and
> this bug report closed as resolved.

Yep.  This *might* be the fix, but at this point I'm not too concerned about tracking it down if everything works:
tdelibs hash 316893

Tim

My patch was focused on testing only. Best that you do the reversing in git.

OK, fixed in GIT hash a3e6305.

Thanks for reporting, and for testing!