Comment 9 for bug 1390923

Revision history for this message
In , Jean-Pierre van Riel (jpvr) wrote :

Created attachment 109164
Cannot identify error in pm-suspend.log and think bug is triggered way before resume scripts run

When first noticing the bug, I did multiple tests and the following pattern are seen in the pm-suspend.log. Unfortunately, I was unable to catch any error here, even when I later modified the script using 'set -x' to try catch which script in the resume process was causing the issue, but that was futile since the resume scripts never even get triggered and the reboot occurs before then. So I think I can rule out any scripts called during resume being the cause.

# When it is able to resume #

Tue Sep 2 00:06:02 SAST 2014: Running hooks for suspend.
...
Tue Sep 2 00:06:02 SAST 2014: performing suspend
Tue Sep 2 00:06:20 SAST 2014: Awake.
Tue Sep 2 00:06:20 SAST 2014: Running hooks for resume
...
Running hook /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend:
/usr/lib/pm-utils/sleep.d/000kernel-change resume suspend: success.

Tue Sep 2 00:06:20 SAST 2014: Finished.

# When it fails to resume #

Tue Sep 2 00:10:19 SAST 2014: Running hooks for suspend.
...
Tue Sep 2 00:10:19 SAST 2014: performing suspend
...
??? not followed by <date>: Awake. ???
...

Instead, in the failure case, we don't get the awake message. The next entry in the log is for the next suspend resume test ater rebooting. I.e. instead of seeing awake, we see the next test.
Tue Sep 2 00:11:34 SAST 2014: Running hooks for suspend.