[Pm-utils] Making cron run after resume?

[Nigel Cunningham]

Hi again.

On Fri, 2008-05-16 at 11:26 +0200, Stefan Seyfried wrote:
> Nigel Cunningham wrote:
> > Hi.
> > 
> > On Fri, 2008-05-16 at 10:42 +0200, Stefan Seyfried wrote:
> 
> >> Remember, refusing to suspend should only happen in very rare cases, i
> >> currently only have a few for suspend to disk:
> >> - the kernel changed (security update), so we know before suspend that we
> >> can't resume
> > 
> > Some code went into vanilla around 2.6.23 IIRC which allows us to resume
> > from a different kernel version, so this shouldn't be an issue anymore.
> 
> Ok, so one less reason to refuse to suspend. (I'm conservative about that
> unless i have heavily tested it, though).

Fair enough, too. I need to do more testing of it myself. Making
software flexible is nice, but it makes for even more combinations for
testing :\

> >> - there is no swap partition or more generally no storage for s2disk
> >> configured => configuration error
> > 
> > Mmm. Not necessarily an issue for TuxOnIce though, as the user can be
> > writing to a file rather than swap (yeah, I know you don't care Stefan,
> > but maybe the others do).
> 
> "or more generally no storage for s2disk". I'm sure there are scenarios for
> tuxonice where you know in advance that calling the suspend method in the
> kernel does not make sense.

Yes.

> ... actually even then, the kernel (or "s2disk") should just return with an
> error code and we can display a hint for the user derived from the error code.

That's what I try to do. I have a 'last_result'' sysfs entry people can
read (but it's a bitmap innterpreted by the hibernate script). I have on
my todo list to add a nicer explanation
to /sys/power/tuxonice/debugging_info before the next release.

> >> "Being unable to apply video workarounds before s2ram" generally cannot happen
> >> IMVHO (but i'm ready to be convinced the other way round).
> >>
> >> Right now, just refusing to suspend and then later exiting with != 0 exit
> >> code, so that the GUIs can display a "suspend had a problem, do you want to
> >> look at the Log file / file a bugreport?" message was pretty effective and
> >> worked very well for me.
> > 
> > Sounds good to me, too.
> 
> And that is what was in the code all the time (unless it was removed recently,
> i have not verified it) without making the hook-running code more complex and
> the rules that hook-writers have to obey more complicated.
> 
> Have fun,

You too :)

Nigel