>> a few days back I noticed that my F29 laptop is hibernated
every morning even
>> though I suspended it the previous evening. After some digging, it seems
>> that there's a new "systemctl suspend-then-hibernate" command that
does
>> exactly this (with a 3 hour delay) and gnome seems to execute it
>> automatically instead of the classic "systemctl suspend".
>>
>> On one hand, this is absolutely awesome, and I've been wanting this for
ages.
>> Windows can do it, general users are used to this, and are usually very
>> surprised when they have a Fedora laptop that drains their battery to 0%
>> during a few days long suspend (that's the case for my wife and my
parents).
>>
>> On the other hand, I'm a bit concerned that the default behavior changed
>> unannounced and doesn't even seem configurable. In gnome-control-center, my
>> power button action is configured to "suspend", yet it clearly
performs
>> "suspend-then-hibernate". There seems to be no way to opt out of this
and
>> use just a classic suspend. Another question is what happens if
>> hibernation/resuming is not configured properly (swap partition missing,
>> resume= argument missing, etc). Have those edge cases been covered?
>>
>> So, my questions are - has this been a deliberate change or is it just some
>> happy coincidence of some systemd+gnome interactions? Will there be some
>> release notes for the users announcing the change? Do plan to make it
>> configurable (allowing users to select between suspend and
>> suspend-then-hibernate)? Should we focus on testing the corner cases?
>>
>> Thanks.
>
>
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d9029...
That commit does not really contain any rationale as to why this is a
good idea, the commit msg basically just says "it is available now,
lets use it".
The kernel's hibernate paths are generally much less tested then
the suspend/resume paths and even suspend/resume already causes
a lot of problems.
This is going to lead to some very "interesting" problems where
systems will not wakeup properly from suspend but only when suspended
during the night, etc.
IMHO this is a bad idea and it should be reverted. At a minimum we
need to keep a close eye on this and disable this by default if
it causes to much problems.
A change this big also should be a proper separate change because it
will add significant load to the kernel team who should also really
agree to it and be well aware of it, which I'm not sure they are.
Peter