[Pm-utils] Re: Dealing with suspend/resume failures
hughsient at gmail.com
Fri Nov 3 11:20:09 PST 2006
On Fri, 2006-11-03 at 12:34 -0500, David Zeuthen wrote:
> On Fri, 2006-11-03 at 17:21 +0000, Richard Hughes wrote:
> > > - For Suspend() let HAL capture the output of the tool being invoked
> > > to a file /var/lib/hal/suspend-output
> > you mean have pm-suspend quit with exit code 3 and report "Device failed
> > to sync" as an example?
> Yea. That would just be in the output. To figure this out you would need
> to look at the debug output through SuspendGetLastError(). Which is
> fine, there's nothing any program can do about it.
> > > - Provide a new method "void SuspendClearLastError()". It will
> > > delete the file /var/lib/hal/suspend-output
> > Ick. What's wrong with just deleting this file the next time we do a
> > system action like shutting down, suspending, hibernating etc? If we
> > didn't fail, then the file won't exist.
> What if the video doesn't come back and the user presses the Power
> button in despair? Then we lose the file...
I never thought of this.
> > > This is to be called by the desktop policy manager (e.g. g-p-m) once
> > > we know that the system is back in a workable state. How does this
> > > work? g-p-m should call this when the session is unlocked since
> > > this is evidence that the user can use his system. In the event
> > > where the session is not locked... I don't know.. perhaps after
> > > 5 minutes or when g-p-m terminates?
> > Seems a bit messy to me.
> No, it's just as soon as we figure out that the system is usable... we
> clear the error... it's not nice, I agree, but really some systems where
> video don't resume are technically usable. The only thing we can do is
> to wait for what looks like intelligent input from the user... e.g. him
> unlocking his session should be good enough.
> If we don't this we get false positives. Suppose that I suspend, then
> resume and then leave my laptop to run dry. Then the next time I boot I
> get a "resume failed!" error which is bogus.
> Of course in the normal situation it's good enough to just clear the
> file when g-p-m terminates but it's not ideal. I don't see what the big
> problem is; just call SuspendClearLastError() whenever g-p-m says the
> session is unlocked?
Easy to implement in the current code.
> > > (OK, so only the first user to login after suspend gets to see the
> > > error. I think that's OK.)
> > Not if you autoclear that on shutdown, next suspend or hibernate.
> I think I already said that the desktop policy manager clears the file
> when it terminates so this is the same. I'm just proposing to cut false
> positives; it's not a big deal really, I can live without g-p-m calling
> SuspendClearLastError() when a session is unlocked, I just think it
> makes the system more robust. What do you think?
Ohh I agree, we should clear it when the user is doing stuff for sure.
When the stuff hits HAL CVS, I'll add support into g-p-m.
More information about the Pm-utils