Dealing with suspend/resume failures

[David Zeuthen]

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

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

> >     (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?

    David