On Tue, 2008-11-04 at 21:55 -0600, Robby Workman wrote: > I've gotten a report of pm-utils failing to work suddenly working > successfully in the past, and through use of PM_DEBUG, I've traced it > to the presence of a stale /var/run/pm-utils/locks/pm-suspend.lock > being present. Looking at /usr/lib/pm-utils/functions, I don't see > anything obviously wrong with locking functions, and of course it > wouldn't be prudent to trap abnormal exits with lock removal, as that > would paper over what's likely a real problem somewhere.
Actually, pm-action removes locks via the shell trap mechanism -- the pm-suspend lock should be removed no matter how the script exits. The only exceptions are if pm-action is kill -9'ed, or if the system is restarted instead of resuming. We don't do anything about the kill -9 case, and on the reboot case there we rely on the FHS spec that says the distro should clean out /var/run on reboot (http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA). Does Slack do that? > Unfortunately, neither I nor the reporter have been able to reproduce > it since that one instance, so I'm at a loss on how to further > troubleshoot this. Has anyone else had this happen, and if so, did you > figure out what was causing it? It used to happen to me all the time while writing the locking code. I haven't seen it happen since we released 1.1.0, though. :) > -RW > _______________________________________________ > Pm-utils mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/pm-utils -- Victor Lowther RHCE# 805008539634727 LPIC-2# LPI000140019 _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
