Dealing with suspend/resume failures

[Richard Hughes]

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.

Yes, indeed.

> > >  - 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.

Sure, agree.

> 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.

Richard.