1:48 p.m.
Hello,
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.
2 p.m.
----- Original Message -----
Hello,
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...
2:44 p.m.
If it works, why should we make it configurable ? I don't think anybody
wants their battery drained...
What corner cases are you thinking of ?
2:58 p.m.
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen <mclasen(a)redhat.com>
wrote:
If it works, why should we make it configurable ? I don't think
anybody wants their battery drained...
What corner cases are you thinking of ?
Kamil is surely worried that the system will attempt to hibernate and
fail, leading to data loss. Historically, we have not exposed hibernate
to users precisely because we expect it to fail. (We are even recently
discussed getting rid of the swap partition!)
It looks like that would be a systemd or kernel bug, because we ask
systemd if hibernate is supported, and do not attempt to hibernate at
all if it's not. Hopefully systemd is right about that in practice....
Michael
3:13 p.m.
On 09/12/2018 09:58 AM, mcatanzaro(a)gnome.org wrote:
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen
<mclasen(a)redhat.com>
wrote:
> If it works, why should we make it configurable ? I don't think
> anybody wants their battery drained...
> What corner cases are you thinking of ?
Kamil is surely worried that the system will attempt to hibernate and
fail,
yeah. i think it *has* to be configurable for this reason. If a bug crops up
in hibernate, you're going to want an escape hatch.
Dusty
3:55 p.m.
----- Original Message -----
On 09/12/2018 09:58 AM, mcatanzaro(a)gnome.org wrote:
> On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen <mclasen(a)redhat.com>
> wrote:
>> If it works, why should we make it configurable ? I don't think
>> anybody wants their battery drained...
>> What corner cases are you thinking of ?
>
> Kamil is surely worried that the system will attempt to hibernate and
> fail,
yeah. i think it *has* to be configurable for this reason. If a bug crops up
in hibernate, you're going to want an escape hatch.
The escape hatch would be in systemd.
9:16 p.m.
On Wed, Sep 12, 2018 at 10:55:01AM -0400, Bastien Nocera wrote:
> yeah. i think it *has* to be configurable for this reason. If a
bug
> crops up in hibernate, you're going to want an escape hatch.
The escape hatch would be in systemd.
I don't really care where the escape hatch lives, but it needs to be
something that can be easily explained to people with frustrating problems,
and which ideally does not involve the command line -- at least, not given
our current positioning.
I don't think we have an easy GUI tool for configuring this kind of thing
for systemd, do we?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6:21 p.m.
On Wed, Sep 12, 2018 at 08:58:46AM -0500, mcatanzaro(a)gnome.org wrote:
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen
<mclasen(a)redhat.com> wrote:
>If it works, why should we make it configurable ? I don't think
>anybody wants their battery drained...
>What corner cases are you thinking of ?
Kamil is surely worried that the system will attempt to hibernate
and fail, leading to data loss. Historically, we have not exposed
hibernate to users precisely because we expect it to fail. (We are
even recently discussed getting rid of the swap partition!)
It looks like that would be a systemd or kernel bug, because we ask
systemd if hibernate is supported, and do not attempt to hibernate
at all if it's not. Hopefully systemd is right about that in
practice....
Systemd checks if there's a swap device and if there's enough space
on it to fit current RSS. If systemd returns true from
org.freedesktop.login1.Manager.CanHibernate or
org.freedesktop.login1.Manager.CanSuspendThenHibernate when those
conditions are not satisfied, that would be a bug.
It also has some other heuristics, e.g. hibernation should be disabled
after a kernel upgrade. But systemd does not check if resume= is set.
I'm sure that are other ways in which this detection is faulty.
In recent times hibernation support in systemd hasn't been getting
much testing, so if it's to be used by default in gnome, more testing
(and reports of bugs) would be very welcome.
It is possible to disable any suspend/hibernation mode using
'systemctl mask suspend.target/hibnerate.target/suspend-then-hibernate.target'.
Zbyszek
6:46 p.m.
On Wed, Sep 12, 2018 at 05:21:03PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 12, 2018 at 08:58:46AM -0500, mcatanzaro(a)gnome.org
wrote:
> On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen
> <mclasen(a)redhat.com> wrote:
> >If it works, why should we make it configurable ? I don't think
> >anybody wants their battery drained...
> >What corner cases are you thinking of ?
>
> Kamil is surely worried that the system will attempt to hibernate
> and fail, leading to data loss. Historically, we have not exposed
> hibernate to users precisely because we expect it to fail. (We are
> even recently discussed getting rid of the swap partition!)
>
> It looks like that would be a systemd or kernel bug, because we ask
> systemd if hibernate is supported, and do not attempt to hibernate
> at all if it's not. Hopefully systemd is right about that in
> practice....
Systemd checks if there's a swap device and if there's enough space
on it to fit current RSS. If systemd returns true from
org.freedesktop.login1.Manager.CanHibernate or
org.freedesktop.login1.Manager.CanSuspendThenHibernate when those
conditions are not satisfied, that would be a bug.
It also has some other heuristics, e.g. hibernation should be disabled
after a kernel upgrade. But systemd does not check if resume= is set.
I'm sure that are other ways in which this detection is faulty.
In recent times hibernation support in systemd hasn't been getting
much testing, so if it's to be used by default in gnome, more testing
(and reports of bugs) would be very welcome.
It is possible to disable any suspend/hibernation mode using
'systemctl mask suspend.target/hibnerate.target/suspend-then-hibernate.target'.
After looking into this some more, I think enabling s2h by default in gnome
is risky:
- systemd does not check for resume=
- systemd does not check if the swap partition is encrypted
(this was OK for "normal" hibernation, where the user is present,
but becomes a problem with s2h)
Arguably those are bugs in systemd, but suddenly we're getting much
bigger exposure. So this should either be reverted in gnome for F29,
or systemd should quickly improve the checks for those two things...
[https://bugzilla.redhat.com/show_bug.cgi?id=1206936 is also related.
Anaconda started adding resume= by default, so for recently installed
systemd resume= will be present.]
Zbyszek
8:11 p.m.
Last I checked (few months), Fedora's kernels inhibit hibernation when
Secure Boot is enabled. That will limit testing to older systems, and
systems where users have disabled Secure Boot.
And also, the Fedora kernel team has been clear they don't have the
resources to triage hibernation related bugs in the kernel. On a
non-Secure Boot Macbook Pro, the hibernation image is corrupt 100% of
the time on resume, which fortunately the kernel detects and thus
rejects, but it slows down boot because it has to read kernel,
initramfs, and the hibernation image from swap, only to reject it and
then proceed with normal boot. And of course there's still data loss,
as the environment isn't restored.
I think supporting hibernation is a neat idea, but it's insufficient.
It's not going to solve most cases of environment state being lost.
And when it doesn't work, users have no idea how to troubleshoot it,
how to file good bug reports. The UX is vastly better saying "nope,
everyone is SOL" rather than a fractured user based, with variable
failure modes, and ignored bug reports.
So I'm gonna re-iterate that GNOME needs to support an application
state saving API. I don't know how good of a design it is, but Firefox
saves its own state and restores itself (usually). And LibreOffice has
some kind of autosave feature. That's what I'm thinking of, but
something standardized that all applications can opt into, to avoid
the problem of losing everything. This burden is placed on all iOS and
Android apps, they don't have hibernation and they don't have Save As
dialogs either.
Chris Murphy
8:52 p.m.
On Wed, Sep 12, 2018 at 3:40 PM Chris Murphy <lists(a)colorremedies.com>
wrote:
And also, the Fedora kernel team has been clear they don't have the
resources to triage hibernation related bugs in the kernel.
[...]
So I'm gonna re-iterate that GNOME needs to support an
application
state saving API.
Interesting juxtaposition. We don't have infinite resources either...
11:09 p.m.
On Wed, Sep 12, 2018 at 1:52 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Wed, Sep 12, 2018 at 3:40 PM Chris Murphy <lists(a)colorremedies.com>
wrote:
>
>
> And also, the Fedora kernel team has been clear they don't have the
> resources to triage hibernation related bugs in the kernel.
[...]
>
> So I'm gonna re-iterate that GNOME needs to support an application
> state saving API.
Interesting juxtaposition. We don't have infinite resources either...
Yep. But hardware, firmware, kernel, systemd domains are obviously a
crap shoot when it comes to hibernation. At least a GNOME solution is
a consistent environment regardless of all of those things, where you
have complete control and introspection.
--
Chris Murphy
9:39 p.m.
On Wed, Sep 12, 2018 at 2:11 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
Last I checked (few months), Fedora's kernels inhibit hibernation
when
Secure Boot is enabled. That will limit testing to older systems, and
systems where users have disabled Secure Boot.
Secure boot resume from hibernation is an issue, it would be nice if
it were fixed, but considering that we consider hibernate harmful (see
below), no one is putting resources to it.
And also, the Fedora kernel team has been clear they don't have
the
resources to triage hibernation related bugs in the kernel. On a
non-Secure Boot Macbook Pro, the hibernation image is corrupt 100% of
the time on resume, which fortunately the kernel detects and thus
rejects, but it slows down boot because it has to read kernel,
initramfs, and the hibernation image from swap, only to reject it and
then proceed with normal boot. And of course there's still data loss,
as the environment isn't restored.
This is the main issue. Hibernation is a horrible mess that works
occasionally. It is almost completely unsupported, because it is so
difficult to support across random hardware. Supposedly, the path
going forward is to no longer need hibernation as it were, using other
low power methods beyond suspend, but this requires new hardware. As
it stands, hibernate fails more often than it works, and the result is
data loss.
I think supporting hibernation is a neat idea, but it's
insufficient.
It's not going to solve most cases of environment state being lost.
And when it doesn't work, users have no idea how to troubleshoot it,
how to file good bug reports. The UX is vastly better saying "nope,
everyone is SOL" rather than a fractured user based, with variable
failure modes, and ignored bug reports.
So I'm gonna re-iterate that GNOME needs to support an application
state saving API. I don't know how good of a design it is, but Firefox
saves its own state and restores itself (usually). And LibreOffice has
some kind of autosave feature. That's what I'm thinking of, but
something standardized that all applications can opt into, to avoid
the problem of losing everything. This burden is placed on all iOS and
Android apps, they don't have hibernation and they don't have Save As
dialogs either.
I would really like to see this. We keep hibernation as an option in
the kernel because it does work for *some* people. I would certainly
not say the majority of people. If this auto hibernation is going to
be an option, it should be opt in, not opt out. Ideally also not
advertised. If Ubuntu seems to feel that hibernation is a priority
for them, and actually put the resources into fixing the kernel for a
majority of machines, that's great. I guess it means they might also
put resources into the secure boot problem. Once it is working, we can
re-evaluate the defaults in Fedora, but until then I am pretty
strongly opposed to this being a default on, opt out thing.
Justin
>
> Chris Murphy
> _______________________________________________
> desktop mailing list -- desktop(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
3:23 p.m.
On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen <mclasen(a)redhat.com> wrote:
If it works, why should we make it configurable ? I don't think
anybody
wants their battery drained...
I'm not omniscient, but I can think of at least a few reasons from the top
of my head:
* Hibernation doesn't work well on your hardware, but suspend does. This
can mean that hibernate doesn't work at all, or that it fails randomly in 1
out of 10 attempts (my personal experience, some firmware is just lovely).
* You prefer fast wake-up time (or e.g. that you don't need to decrypt your
hard drive again) to a longer hibernation resume and you know it won't be
long before you're going to wake up the device (e.g. an office laptop, to
be woken up each morning).
* You want to prevent people from inadvertently booting OS2 while OS1 is
hibernated, because that can easily destroy filesystems (when they are
mounted to both). A real world example is Linux+Windows installed on a
desktop/laptop with a Windows partition mounted in Linux. If user1 suspends
Linux (which later hibernates), a user2 starts the computer and boots into
Windows, and then later anyone boots into Linux again (which resumes from
hibernation), the Windows filesystem can easily get corrupted. This would
not happen if the computer was always just suspended, but can easily happen
if the system starts stealthily hibernating later (and you can even disable
it).
Don't take me wrong, I think this behavior is great and is a much better
default for a general audience. But you asked why would anyone want to
configure it, and I believe there are solid use cases and their users
shouldn't thrown under the bus. I have at least one colleague who said he
really prefers standard suspend over suspend-then-hibernate. There will be
users like this.
What corner cases are you thinking of ?
In my original email I wrote "swap partition missing, resume= argument
missing". One more can be "swap too small". Maybe systemd can all of it
handle well. I'm interested to know whether this has been tested at least
in some extent, or whether more QA focus is appreciated here. Since this
will affect all Fedora 29 users, we should ensure it will not break
spectacularly in common cases.
4:26 p.m.
I agree with Bastien. If an escape hatch is needed, it belongs in systemd.
Not something to expose in the control-center as a user choice.
On Wed, Sep 12, 2018 at 10:56 AM Kamil Paral <kparal(a)redhat.com> wrote:
On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen
<mclasen(a)redhat.com>
wrote:
> If it works, why should we make it configurable ? I don't think anybody
> wants their battery drained...
>
I'm not omniscient, but I can think of at least a few reasons from the top
of my head:
* Hibernation doesn't work well on your hardware, but suspend does. This
can mean that hibernate doesn't work at all, or that it fails randomly in 1
out of 10 attempts (my personal experience, some firmware is just lovely).
* You prefer fast wake-up time (or e.g. that you don't need to decrypt
your hard drive again) to a longer hibernation resume and you know it won't
be long before you're going to wake up the device (e.g. an office laptop,
to be woken up each morning).
* You want to prevent people from inadvertently booting OS2 while OS1 is
hibernated, because that can easily destroy filesystems (when they are
mounted to both). A real world example is Linux+Windows installed on a
desktop/laptop with a Windows partition mounted in Linux. If user1 suspends
Linux (which later hibernates), a user2 starts the computer and boots into
Windows, and then later anyone boots into Linux again (which resumes from
hibernation), the Windows filesystem can easily get corrupted. This would
not happen if the computer was always just suspended, but can easily happen
if the system starts stealthily hibernating later (and you can even disable
it).
Don't take me wrong, I think this behavior is great and is a much better
default for a general audience. But you asked why would anyone want to
configure it, and I believe there are solid use cases and their users
shouldn't thrown under the bus. I have at least one colleague who said he
really prefers standard suspend over suspend-then-hibernate. There will be
users like this.
> What corner cases are you thinking of ?
>
In my original email I wrote "swap partition missing, resume= argument
missing". One more can be "swap too small". Maybe systemd can all of it
handle well. I'm interested to know whether this has been tested at least
in some extent, or whether more QA focus is appreciated here. Since this
will affect all Fedora 29 users, we should ensure it will not break
spectacularly in common cases.
_______________________________________________
desktop mailing list -- desktop(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
4:38 p.m.
On 09/12/2018 11:26 AM, Matthias Clasen wrote:
I agree with Bastien. If an escape hatch is needed, it belongs in
systemd. Not something to expose in the control-center as a user choice.
From a software design/"who is responsible" point of view I honestly don't
know what the best
answer is. Probably systemd. I would like to play devil's advocate, though, with the
following
quesiton:
If the user were looking to disable this behavior where is the first place they would
look?
Dusty
5:19 p.m.
On Wed, 2018-09-12 at 16:23 +0200, Kamil Paral wrote:
On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen
<mclasen(a)redhat.com> wrote:
> If it works, why should we make it configurable ? I don't think anybody
> wants their battery drained...
>
I'm not omniscient, but I can think of at least a few reasons from the top
of my head:
* Hibernation doesn't work well on your hardware, but suspend does. This
can mean that hibernate doesn't work at all, or that it fails randomly in 1
out of 10 attempts (my personal experience, some firmware is just lovely).
* You prefer fast wake-up time (or e.g. that you don't need to decrypt your
hard drive again) to a longer hibernation resume and you know it won't be
long before you're going to wake up the device (e.g. an office laptop, to
be woken up each morning).
FWIW this is exactly my use case. I keep my main laptop plugged in in
my office, and close to lid to suspend it each evening. Some time the
next day I'm gonna open it again. I'd prefer it wake up quickly, and as
it's plugged in, there's no need for it to hibernate.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:22 p.m.
On Wed, 2018-09-12 at 09:19 -0700, Adam Williamson wrote:
On Wed, 2018-09-12 at 16:23 +0200, Kamil Paral wrote:
> On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen <mclasen(a)redhat.com> wrote:
>
> > If it works, why should we make it configurable ? I don't think anybody
> > wants their battery drained...
> >
>
> I'm not omniscient, but I can think of at least a few reasons from the top
> of my head:
> * Hibernation doesn't work well on your hardware, but suspend does. This
> can mean that hibernate doesn't work at all, or that it fails randomly in 1
> out of 10 attempts (my personal experience, some firmware is just lovely).
> * You prefer fast wake-up time (or e.g. that you don't need to decrypt your
> hard drive again) to a longer hibernation resume and you know it won't be
> long before you're going to wake up the device (e.g. an office laptop, to
> be woken up each morning).
FWIW this is exactly my use case. I keep my main laptop plugged in in
my office, and close to lid to suspend it each evening. Some time the
next day I'm gonna open it again. I'd prefer it wake up quickly, and as
it's plugged in, there's no need for it to hibernate.
BTW, I'll also note that while Apple was the pioneer in this, AIUI
their implementation is more sophisticated. AIUI it's basically a true
hybrid mode: the system sort of suspends and hibernates simultaneously,
leaving the RAM powered but *also* writing the state to disk. So long
as the system retains power, on resume it will resume from RAM. If
power is lost, it falls back to resuming from disk.
That would have none of the drawbacks of this less sophisticated
implementation, where it seems that after 3 hours, you're solely
relying on the 'hibernate' mechanism to work.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:30 p.m.
On Wed, Sep 12, 2018 at 10:22 AM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
BTW, I'll also note that while Apple was the pioneer in this, AIUI
their implementation is more sophisticated. AIUI it's basically a true
hybrid mode: the system sort of suspends and hibernates simultaneously,
leaving the RAM powered but *also* writing the state to disk. So long
as the system retains power, on resume it will resume from RAM. If
power is lost, it falls back to resuming from disk.
Correct. It's called "Safe Sleep" (hibernatemode 3 or 25). It writes
out a sleep file to the rootfs, and then goes into (effectively) S3
suspend to RAM.
It also inserts a hint in NVRAM so that the firmware or bootloader
(depends on OS version and hardware) can directly eat that sleep file
on resume.
Windows has a variation on this that it uses for all shutdowns: fast
startup. It closes user apps and logs out the user, then creates a
hibernation file of this state, then shuts down. It also has a hint
for the bootloader to directly eat this file on cold startup. It
really is quite fast. Restarts do not use fast startup. So you have
this curious case where a reboot is closer to what you think a cold
boot is, than an actual cold boot (which is fast startup).
That would have none of the drawbacks of this less sophisticated
implementation, where it seems that after 3 hours, you're solely
relying on the 'hibernate' mechanism to work.
Pretty sure 'systemctl hybrid-sleep' is close to what you're after,
which is "suspend-to-both".
--
Chris Murphy
7:56 p.m.
Hi,
On 12-09-18 15:00, Bastien Nocera wrote:
----- Original Message -----
> Hello,
>
> 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.
Regards,
Hans
8:29 p.m.
On Mi, 12.09.18 20:56, Hans de Goede (hdegoede(a)redhat.com) wrote:
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.
I am bit concerned about this too.
The s2h code in systemd has been contributed by Ubuntu folks, but as I
just learnt it doesn't even work entirely correctly there... The big
issue afaics is that some non-trivial parts are still missing on the
resume side of things (i.e. entering hibernation is mostly complete,
but leaving hibernation is messy), and we need more safety checks to
figure out when this all is known to be safe. The Ubuntu folks don't
use dracut as ther initrd, but use some ubunut/debian specific initrd
that doesn't use systemd, so they hacked the resume code fully into
that, but we are still missing the same bits in our codepaths...
Moreover, I really don't like the idea that resume= and resume_offset=
has to be specified on the kernel cmdline for picking the swap
partition/file. We really should make this nicer and automatically
detect everything, so that this all works safely even with an empty
kernel cmdline.
Hence, I think this is too early to enable in Fedora I think. So far
hibernation was something that Fedora/RH didn't care too much about as
I understood, so it never was a priority for us to implement
comprehensively, and only merged contributed patches. Before we hook
this all into Fedora properly we should really do our homework
comprehensively, and add the missing bits to make this safe.
(And that's just the concerns on the systemd side of things. There's
also the problem that the kernel code isn't the best tested in the
world since afaik no bigger distribution defaulted to hibernation so
far. But I guess this shouldn't stop us from turning it on in Rawhide
at least)
So, here's what I think needs to be dealt with first on the systemd
side:
1. make systemd's resume support independent of resume= and
resume_offset= on the kernel cmdline, i.e. add auto-detection of
hibrenation images on boot, and add support for a "noresume" kernel
cmdline option to disable that auto-detection and such. (i.e. make
this automatic and independent of anaconda)
2. tighten the checks when this all is safe, i.e. filter out swap on
weird storage
3. figure out what to do about swap on luks (maybe simply refuse in
that case, i.e. treat as "weird storage")
4. make sure that resume from swap files works (it currently certainly
does not)
5. add a nice way to disable this locally and revert back to plain suspend
(with input from Zbigniew)
With the above systemd changes it's probably fine to start enabling
this in Rawhide for some testing, but it's definitely something that
needs announcement and a clear path to reverting this before the
release, and moving back to plain suspend. (i figure it might be
something to file a fedora feature about, too)
Also, I'd be interested in a fedora kernel maintainer's opinion on
this, if they thing this is something supportable.
Lennart
--
Lennart Poettering, Red Hat
8:55 p.m.
On Wed, Sep 12, 2018 at 09:29:56PM +0200, Lennart Poettering wrote:
On Mi, 12.09.18 20:56, Hans de Goede (hdegoede(a)redhat.com) wrote:
3. figure out what to do about swap on luks (maybe simply refuse in
that case, i.e. treat as "weird storage")
Encryption should be required, not treated as "weird".
9:21 p.m.
On Wed, Sep 12, 2018 at 03:55:13PM -0400, Chuck Anderson wrote:
On Wed, Sep 12, 2018 at 09:29:56PM +0200, Lennart Poettering wrote:
> On Mi, 12.09.18 20:56, Hans de Goede (hdegoede(a)redhat.com) wrote:
> 3. figure out what to do about swap on luks (maybe simply refuse in
> that case, i.e. treat as "weird storage")
Encryption should be required, not treated as "weird".
Yeah, actually encryption should be OK.
I had a moment of confusion that it causes a problem for s2h, but
actually it doesn't.
Zbyszek
9:25 p.m.
>> 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
12:02 a.m.
On Wed, Sep 12, 2018 at 8:00 AM, Bastien Nocera <bnocera(a)redhat.com>
wrote:
Bastien,
It seems (a) more work is required in systemd, and (b) even if that
work were completed, it's still unsupported and expected to fail at the
kernel level.
Will you reconsider the upstream behavior?
Michael
9:31 a.m.
On Thu, Sep 13, 2018 at 1:03 AM <mcatanzaro(a)gnome.org> wrote:
On Wed, Sep 12, 2018 at 8:00 AM, Bastien Nocera <bnocera(a)redhat.com>
wrote:
>
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d9029...
Bastien,
It seems (a) more work is required in systemd, and (b) even if that
work were completed, it's still unsupported and expected to fail at the
kernel level.
Will you reconsider the upstream behavior?
I'd like to re-iterate that I *love* the new behavior (hibernation works
perfectly on my hardware). I'd like suspend-then-hibernate to stay as an
option in gnome, even if it is not the default behavior. If gnome decides
to go back to standard suspend by default, can you please keep
suspend-then-hibernate as an option? It would be completely fine if this
wasn't even exposed in the control-center, but just in the tweak-tool or
even just in dconf.
My pet peeve in gnome about this is that the hardcoded offered options
don't match all the available options in systemd (for example hybrid-sleep
is completely missing, and now even standard suspend is missing) and
there's no viable option to configure power button/lid close behavior
outside of the hardcoded options. You can configure everything in
logind.conf, but gnome never lets you use that configuration, because it
always consumes the event. Even if you choose "do nothing" in
control-center, it consumes it and doesn't forward it to systemd (makes
sense, but...). On specific hardware that I knew it needed some special
treatment, I wasn't able to set the right behavior, when in gnome. It's
very disappointing when you spend days or weeks debugging faulty
hardware/firmware, finally arrive at a working solution, and then you're
blocked by a missing item in a drop-down menu. And the only way how to make
it work is to switch to a console tty before closing the lid (so that
logind.conf configuration is used). Good luck teaching that your wife.
Perhaps you could simply add a dconf option to let gnome completely ignore
power button/lid close signals and let systemd handle that? That would make
hopefully you happy (no additional options in the gui), the power users
happy (able to configure everything through logind.conf), and users with
problematic hardware happy (logind.conf again, possibly after getting an
advice online).
10:58 a.m.
----- Original Message -----
On Wed, Sep 12, 2018 at 8:00 AM, Bastien Nocera <bnocera(a)redhat.com>
wrote:
>
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d9029...
Bastien,
It seems (a) more work is required in systemd, and (b) even if that
work were completed, it's still unsupported and expected to fail at the
kernel level.
Will you reconsider the upstream behavior?
I'm not the upstream (or downstream) maintainer, I wasn't the author, or the
committer but if it doesn't work in systemd, then it simply needs to disable
that feature, the code will happily not use the feature if the
"CanSuspendThenHibernate" call fails.
It shouldn't require any changes in GNOME.
I should also note that I'm really not interested in discussing power management
with Fedora anymore, the decision last cycle to disable automatic suspend was
the last straw. Fedora didn't put any pressure on mutter maintainers to have the
fix necessary for the feature to work as expected, I had to write the mutter patches
myself upstream, which weren't picked up by Fedora and waited until a .1 upstream
release to be merged.
The patches were working and available before you chose to revert the behaviour in
Fedora, despite me repeatedly saying that the problem should be fixed in mutter, and
with no clear forward path as to when that change in configuration compared to upstream
would be removed. It's still there in the F29 betas:
https://src.fedoraproject.org/cgit/rpms/gnome-settings-daemon.git/tree/or...
2 p.m.
On Thu, Sep 13, 2018 at 05:58:14AM -0400, Bastien Nocera wrote:
I should also note that I'm really not interested in discussing
power management
with Fedora anymore, the decision last cycle to disable automatic suspend was
the last straw. Fedora didn't put any pressure on mutter maintainers to have the
fix necessary for the feature to work as expected, I had to write the mutter patches
myself upstream, which weren't picked up by Fedora and waited until a .1 upstream
release to be merged.
Bastien, who is "Fedora" in this complaint? I expect that things like this
would be discussed and worked out in the Fedora Workstation Working Group,
or among members of the "gnome-sig" group (which has commit access to
mutter, and where I see that you are a member:
https://src.fedoraproject.org/group/gnome-sig).
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:46 p.m.
----- Original Message -----
On Thu, Sep 13, 2018 at 05:58:14AM -0400, Bastien Nocera wrote:
> I should also note that I'm really not interested in discussing power
> management
> with Fedora anymore, the decision last cycle to disable automatic suspend
> was
> the last straw. Fedora didn't put any pressure on mutter maintainers to
> have the
> fix necessary for the feature to work as expected, I had to write the
> mutter patches
> myself upstream, which weren't picked up by Fedora and waited until a .1
> upstream
> release to be merged.
Bastien, who is "Fedora" in this complaint? I expect that things like this
would be discussed and worked out in the Fedora Workstation Working Group,
or among members of the "gnome-sig" group (which has commit access to
mutter, and where I see that you are a member:
https://src.fedoraproject.org/group/gnome-sig).
The Fedora Workstation Working Group in this case:
https://pagure.io/fedora-workstation/issue/42
2050
days inactive
2051
days old
desktop@lists.fedoraproject.org
28 comments
14 participants
participants (14)
-
Adam Williamson -
Bastien Nocera -
Chris Murphy -
Chuck Anderson -
Dusty Mabe -
Hans de Goede -
Justin Forbes -
Kamil Paral -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
mcatanzaro＠gnome.org -
Peter Robinson -
Zbigniew Jędrzejewski-Szmek