[systemd-devel] [hybrid-sleep] hibernation delay

[Lennart Poettering]

On Fri, 20.06.14 16:32, Mantas Mikulėnas (grawity at gmail.com) wrote:

> > On Fri, 13.06.14 18:54, Tom Sherpen (tomsherpen at mail.com) wrote:
> >
> >>    Hi,
> >>
> >>    I am wondering if hybrid-sleep could support a hibernation delay, similar
> >>    to what is found in pm-utils [1]
> >>
> >>    Thus, you would be able to first suspend, with the machine going
> >>    automatically into hibernation after a certain amount of time.
> >>
> >>    Is support for such a hibernation delay planned for the future?
> >
> > This is currently not implemented. We could certainly add something like
> > this to the systemd-sleep binary, however, I am not entirely sure how to
> > do this reliably: if we do this in userspace, and first set up a timer
> > that will resume the machine, then go to suspend, how do we figure out
> > after resume whether we resumed because of this timer (and hence we
> > should go to hibernation, immediately) or because of some user activity?
> 
> I think this is usually done by comparing if the clock after wakeup ==
> (clock before wakeup + hibernation delay + ...maybe clock drift?).
> 
> [In other words, ugly hack from before s2both days.]

So you mean that we should check if after wakeup the time is within a
5min window or so around the time we set our timer to, and if that's the
case, then we assume we woke up because of this timer-hybrid-sleep
thing? That sounds awfully black-magicy to me. If people happen to
manually resume the machine precisely in that 5min window then the
machine will immediately go to hibernation. That sounds really wrong to
me.

I am really not a fan of mechanisms that usually work, but sometimes
don't. That's nothing I want to support. Sorry. 

If you can provide me with a kernel API or so that precisely tell us
that one specific timerfd or so caused a resume, then I am all ears, but
otherwise this is not going to happen. Sorry.

If there's value in implementing something like this, then fix the
kernel first, and we will make use of it. But we will not work-around
lack of support from the kernel for this kind of thing.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat