Package: pm-utils Version: 1.2.6.1-3 Severity: grave Justification: most basic robustness principles violated, by a core system package
AFAICS even a single unfortunate failure during suspend usage can render pm-suspend support terminally broken, with subsequent attempts always exiting immediately, without any logging to occur (not even when trying to get help by running pm-suspend --help or so) [I realize that hitting an occupied lock probably shouldn't get logged, though]. Possible failure leading to pm-suspend breakage includes - simple loss of power (notebook battery, wall socket) while suspended - a crash during suspend \ both rather common - a crash during resume / behaviour, sadly The only way to trace failure is to run sh -x or define PM_SUSPEND, which then outputs: +++ return 0 +++ check_hibernate +++ '[' -n uswsusp ']' +++ SUSPEND_HYBRID_MODULE=uswsusp +++ '[' suspend = suspend_hybrid ']' ++ '[' -z uswsusp ']' ++ '[' -z uswsusp ']' ++ id -u + '[' 0 '!=' 0 ']' + try_lock pm-suspend.lock + mkdir -p /var/run/pm-utils/locks + local lock=/var/run/pm-utils/locks/pm-suspend.lock + return 1 + exit 1 /var/run/pm-utils/locks/pm-suspend.lock turns out to be about as old as my grandmother: -rw-r--r-- 1 root root 1 11-09 07:52 /var/run/pm-utils/locks/pm-suspend.lock Filing the report now to get things rolling, may continue investigation on how to fix the problem (possibly by checking age of lock and removing if older than 1 day or so). Note that there isn't any init script available either which might have removed a stale lock as one of its tasks... Since most users are likely to invoke pm-suspend via implementation-hiding frontends, they'll never know what hit them. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
