Ok. In the process of testing this I think I have hit the actual cause of the issue. If a resume fails late on say resuming bluetooth then the resume may have gotten far enough that the user in front of the screen percieves the machine to be fully functional. They may well see the screen lock and be able to login. About the only thing which will not work is a second attempt to suspend which should at most be able to lock the screensaver. If the user (even much) later reboots the machine the failure will be detected and reported. The user has not seen any problem and reasonably will believe that the suspend/resume failure report is false.
We need to enhance the reporting to catch this case and record the information we need as soon as this is detected. Pretty much we can only tell when we are asked to shutdown. At this point we can see that there is still a suspend/hibernate in progress and we are in a position to check for the presence of the hanging processes. We should also report this as a different type of failure to make it clear that it was the resume and that it would have appeared just fine. We should also be recording the basic suspend logs in the apport bugs. -- resume hangs late in the process appear working and yet report failure on next reboot https://bugs.launchpad.net/bugs/335323 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
