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.
----- 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/a6e3ee40d90294c6...
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 ?
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen mclasen@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
On 09/12/2018 09:58 AM, mcatanzaro@gnome.org wrote:
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen mclasen@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
----- Original Message -----
On 09/12/2018 09:58 AM, mcatanzaro@gnome.org wrote:
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen mclasen@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.
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?
On Wed, Sep 12, 2018 at 08:58:46AM -0500, mcatanzaro@gnome.org wrote:
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen mclasen@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
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@gnome.org wrote:
On Wed, Sep 12, 2018 at 8:44 AM, Matthias Clasen mclasen@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
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
On Wed, Sep 12, 2018 at 3:40 PM Chris Murphy lists@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...
On Wed, Sep 12, 2018 at 1:52 PM, Matthias Clasen mclasen@redhat.com wrote:
On Wed, Sep 12, 2018 at 3:40 PM Chris Murphy lists@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.
On Wed, Sep 12, 2018 at 2:11 PM, Chris Murphy lists@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@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@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.or...
On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen mclasen@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.
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@redhat.com wrote:
On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen mclasen@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@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@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.or...
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
On Wed, 2018-09-12 at 16:23 +0200, Kamil Paral wrote:
On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen mclasen@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.
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@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.
On Wed, Sep 12, 2018 at 10:22 AM, Adam Williamson adamwill@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".
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/a6e3ee40d90294c6...
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
On Mi, 12.09.18 20:56, Hans de Goede (hdegoede@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
On Wed, Sep 12, 2018 at 09:29:56PM +0200, Lennart Poettering wrote:
On Mi, 12.09.18 20:56, Hans de Goede (hdegoede@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".
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@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
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/a6e3ee40d90294c6...
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
On Wed, Sep 12, 2018 at 8:00 AM, Bastien Nocera bnocera@redhat.com wrote:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d90294c6...
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
On Thu, Sep 13, 2018 at 1:03 AM mcatanzaro@gnome.org wrote:
On Wed, Sep 12, 2018 at 8:00 AM, Bastien Nocera bnocera@redhat.com wrote:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d90294c6...
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).
----- Original Message -----
On Wed, Sep 12, 2018 at 8:00 AM, Bastien Nocera bnocera@redhat.com wrote:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d90294c6...
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/org.g...
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).
----- 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
desktop@lists.fedoraproject.org