Disable (or make configurable and default to off) suspend-then-hibernate behavior in GNOME-3.30
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
Regards,
Hans
----- Original Message -----
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
Benjamin
Hi,
On 13-09-18 16:16, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
My reaction to Bastien and yours crossed, right gsd-power has no configuration option now. What I'm suggesting is, that since some people want this to be opt-in, we add such a configuration option.
This really is a policy decision and as such belongs in GNOME IMHO systemd simply provides a mechanism for this and the availability call it has is to indicate if the hardware can support this at all (with no guarantees about this working).
Either way we need to do something about this for F29.
Regards,
Hans
----- Original Message -----
Hi,
On 13-09-18 16:16, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
My reaction to Bastien and yours crossed, right gsd-power has no configuration option now. What I'm suggesting is, that since some people want this to be opt-in, we add such a configuration option.
This really is a policy decision and as such belongs in GNOME IMHO systemd simply provides a mechanism for this and the availability call it has is to indicate if the hardware can support this at all (with no guarantees about this working).
Either way we need to do something about this for F29.
It's broken. systemd will use it when GNOME isn't involved, therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
Disabling the support at the systemd level is as easy as masking a target. Somebody interested in using the feature just needs to unask a target, without needing to make changes to GNOME on top of that.
This is what you want to do.
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
Hi,
On 13-09-18 16:40, Bastien Nocera wrote:
----- Original Message -----
Hi,
On 13-09-18 16:16, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
My reaction to Bastien and yours crossed, right gsd-power has no configuration option now. What I'm suggesting is, that since some people want this to be opt-in, we add such a configuration option.
This really is a policy decision and as such belongs in GNOME IMHO systemd simply provides a mechanism for this and the availability call it has is to indicate if the hardware can support this at all (with no guarantees about this working).
Either way we need to do something about this for F29.
It's broken. systemd will use it when GNOME isn't involved, therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
Without an easy way for people to test this it will be broken for ever.
A feature like this needs to have an easy way to opt in, so that we can get people to test this and report issues (or success). So that we can improve the hw support over time until we feel comfortable to at least try to enable this by default.
Anyway I'm done with this discussion, whether this is disabled at the systemd level or the g-s-d level is not really that important, the important thing is that it is disabled.
So I will leave the discussion to decide where to disable this as something to discuss between the g-s-d maintainers and the systemd maintainers.
Regards,
Hans
On Thu, Sep 13, 2018 at 11:10 AM Hans de Goede hdegoede@redhat.com wrote:
Without an easy way for people to test this it will be broken for ever.
A feature like this needs to have an easy way to opt in, so that we can get people to test this and report issues (or success). So that we can improve the hw support over time until we feel comfortable to at least try to enable this by default.
It will be broken forever, since the kernel team can't support it, from what I hear. We should just remove hibernation support from the Fedora kernel. No point in haggling about an easy way to opt-in to a feature that is not supported.
On Thu, Sep 13, 2018 at 12:00 PM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Sep 13, 2018 at 11:10 AM Hans de Goede hdegoede@redhat.com wrote:
Without an easy way for people to test this it will be broken for ever.
A feature like this needs to have an easy way to opt in, so that we can get people to test this and report issues (or success). So that we can improve the hw support over time until we feel comfortable to at least try to enable this by default.
It will be broken forever, since the kernel team can't support it, from what I hear. We should just remove hibernation support from the Fedora kernel. No point in haggling about an easy way to opt-in to a feature that is not supported.
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes jmforbes@linuxtx.org wrote:
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
Well, everything worked for somebody at some point. But the answer can't be to just add another toggle to the control-center so people can experimentally find out if it works for them at this time, choose-your-own-adventure style.
Either we commit to supporting it. Then we need to invest the time to make it actually work. At the minimum, we need to be able to detect reliably when it will not work, so we can turn it off.
Or we don't. In which case we should just remove it.
On Thu, Sep 13, 2018 at 12:21 PM, Matthias Clasen mclasen@redhat.com wrote:
Well, everything worked for somebody at some point. But the answer can't be to just add another toggle to the control-center so people can experimentally find out if it works for them at this time, choose-your-own-adventure style.
Either we commit to supporting it. Then we need to invest the time to make it actually work. At the minimum, we need to be able to detect reliably when it will not work, so we can turn it off.
Or we don't. In which case we should just remove it.
This makes sense to me.
It seems like we can't detect reliably when hibernation is not going to work at the kernel level, so that suggests removal to me. Hibernation shouldn't be an adventure to figure out whether it works on particular hardware or not.
Michael
On Thu, Sep 13, 2018 at 11:21 AM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes jmforbes@linuxtx.org wrote:
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
Well, everything worked for somebody at some point. But the answer can't be to just add another toggle to the control-center so people can experimentally find out if it works for them at this time, choose-your-own-adventure style.
I agree it shouldn't be generally available, as it's in effect experimental.
Either we commit to supporting it. Then we need to invest the time to make it actually work. At the minimum, we need to be able to detect reliably when it will not work, so we can turn it off.
It's possibly not even a question for a kernel developer specializing in power management issues can answer.
e.g. one of my newer laptops, an HP Spectre, suspends to RAM (S3) just fine in Windows; but then it stopped working due to a Linux kernel update. After bisecting that, they said the changes could not possibly be related, and after a lot of ACPI debugging they gave up and said it must be a firmware bug contact the vendor, who basically say well it works on Windows. In the meantime, I'm able to suspect with [chris@f29h ~]$ cat /etc/tmpfiles.d/suspendfix.conf ## Fix suspend bug w /proc/acpi/wakeup - - - - PWRB
How could that requirement be detected reliably? I think it's unlikely that Microsoft is working around these problems on a case by case basis. It seems more likely the hardware vendors are tweaking their firmware to make certain it works with the Windows implementation. Apple on the other hand could be doing it either way.
Hi,
On Thu, Sep 13, 2018 at 1:21 PM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes jmforbes@linuxtx.org wrote:
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
Well, everything worked for somebody at some point. But the answer can't be to just add another toggle to the control-center so people can experimentally find out if it works for them at this time, choose-your-own-adventure style.
Either we commit to supporting it. Then we need to invest the time to make it actually work. At the minimum, we need to be able to detect reliably when it will not work, so we can turn it off.
Or we don't. In which case we should just remove it.
Right, the kernel should stop advertising "disk" in /sys/power/state unless it can reliably hibernate. If users want to opt-in to some hibernate tech-preview, they should have to add something to the kernel command line or so, imo.
The kernel shouldn't be exposing features it can't reliably provide. Again, as I understand it, it's not even a hardware-supported situation, it can potentially fail on *any system* if the swap partition is filled up the wrong way, if i'm not mistaken.
until, at least that is fixed, we really should stop exposing the feature without some sort of kernel command line opt-in situation.
--Ray
----- Original Message -----
Hi,
On Thu, Sep 13, 2018 at 1:21 PM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes jmforbes@linuxtx.org wrote:
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
Well, everything worked for somebody at some point. But the answer can't be to just add another toggle to the control-center so people can experimentally find out if it works for them at this time, choose-your-own-adventure style.
Either we commit to supporting it. Then we need to invest the time to make it actually work. At the minimum, we need to be able to detect reliably when it will not work, so we can turn it off.
Or we don't. In which case we should just remove it.
Right, the kernel should stop advertising "disk" in /sys/power/state unless it can reliably hibernate. If users want to opt-in to some hibernate tech-preview, they should have to add something to the kernel command line or so, imo.
The kernel shouldn't be exposing features it can't reliably provide. Again, as I understand it, it's not even a hardware-supported situation, it can potentially fail on *any system* if the swap partition is filled up the wrong way, if i'm not mistaken.
There's multiple levels of "support". The kernel doesn't know if it has enough swap, this is checked by user-space, systemd in this case. Any additional checks we'd want to make would probably be implemented in systemd, so it can answer "CanHibernate" with a better degree of certainty.
until, at least that is fixed, we really should stop exposing the feature without some sort of kernel command line opt-in situation.
I think that the kernel doesn't have enough information about the system to be able to make the decision in a lot of cases, or it would cross subsystem boundaries. For example, knowing if Secure Boot is enabled, whether there's data encryption enabled, whether grub is correctly setup.
Having more checks in systemd might help. As for when the hardware drivers need fixing, well, it's the same situation as for any other driver bug would be, and hopefully fixed.
Anyway, I'm becoming increasingly convinced that any amount of swap is a misfeature. In practice, when applications start using swap, it means Fedora grinds to a halt from thrashing and needs to be force powered off.
We've been considering switching to a swap file (like Ubuntu), but perhaps the should be no swap at all.
Michael
On Fri, Sep 14, 2018 at 9:16 AM, mcatanzaro@gnome.org wrote:
Anyway, I'm becoming increasingly convinced that any amount of swap is a misfeature. In practice, when applications start using swap, it means Fedora grinds to a halt from thrashing and needs to be force powered off.
I think it's just as problematic if the system is under memory pressure without sufficient swap, the kernel invokes OOM killer. My experience with OOM killer is in the realm of "ok so why don't you just kill...oh nice there goes sshd...I'm screwed" rather than killing firefox or chrome. I haven't dug into any of the logic the OOM killer is using, or whether it's configurable. But yeah top on my list of things to kill is the web browser because it has a session restore :-) and tends to be the biggest memory pig on the system by far.
Two ways to reduce the need for drive swap: zram device backed swap as the highest priority with an optional fallback on a disk based swap; or zswap which reserves a pool in memory with automatic fallback to disk swap. I've been using zswap for some time, and it moderates the abrupt performance loss that comes with traditional disk based swap.
We've been considering switching to a swap file (like Ubuntu), but perhaps the should be no swap at all.
I'm pretty sure hibernate (suspend to disk) does not support files. So I'll be slightly curious if, with all the hibernation work Ubuntu is apparently doing, they end up going with partitions or if they've got some other trick up their sleeve, like teaching the bootloader how to find and resume hibernation from a file.
At least on Windows and macOS, the hibernation file is a separate thing from swapfiles. Maybe there's a good reason for this distinction, I'm not sure.
On Fri, 2018-09-14 at 17:47 -0600, Chris Murphy wrote:
I haven't dug into any of the logic the OOM killer is using, or whether it's configurable.
I believe the function is named "do_ya_feel_lucky_punk?_well_do_ya?()"
On Fri, Sep 14, 2018 at 6:47 PM, Chris Murphy lists@colorremedies.com wrote:
I think it's just as problematic if the system is under memory pressure without sufficient swap, the kernel invokes OOM killer. My experience with OOM killer is in the realm of "ok so why don't you just kill...oh nice there goes sshd...I'm screwed" rather than killing firefox or chrome. I haven't dug into any of the logic the OOM killer is using, or whether it's configurable. But yeah top on my list of things to kill is the web browser because it has a session restore :-) and tends to be the biggest memory pig on the system by far.
Is that really worse? Thing is, when Fedora Workstation starts swapping, the user loses control of the desktop and the only practical solution is to hold the power button. Hard to imagine losing random processes would be worse than that. (Let's not optimize for sshd; this is Workstation after all.)
We handle swap really, *really* badly. I'm inclined to think that if we want to keep it, this situation needs to dramatically improve to guarantee that desktop interactivity isn't compromised.
On Fri, Sep 14, 2018 at 6:47 PM, Chris Murphy lists@colorremedies.com wrote:
I'm pretty sure hibernate (suspend to disk) does not support files. So I'll be slightly curious if, with all the hibernation work Ubuntu is apparently doing, they end up going with partitions or if they've got some other trick up their sleeve, like teaching the bootloader how to find and resume hibernation from a file.
Sorry, I was unclear: Ubuntu already switched to swap files in 17.04. Done deal.
Michael
On Fri, Sep 14, 2018 at 8:18 PM, mcatanzaro@gnome.org wrote:
On Fri, Sep 14, 2018 at 6:47 PM, Chris Murphy lists@colorremedies.com wrote:
I think it's just as problematic if the system is under memory pressure without sufficient swap, the kernel invokes OOM killer. My experience with OOM killer is in the realm of "ok so why don't you just kill...oh nice there goes sshd...I'm screwed" rather than killing firefox or chrome. I haven't dug into any of the logic the OOM killer is using, or whether it's configurable. But yeah top on my list of things to kill is the web browser because it has a session restore :-) and tends to be the biggest memory pig on the system by far.
Is that really worse? Thing is, when Fedora Workstation starts swapping, the user loses control of the desktop and the only practical solution is to hold the power button. Hard to imagine losing random processes would be worse than that. (Let's not optimize for sshd; this is Workstation after all.)
OOM killer might be worse if it's really arbitrary or non-configurable. What if it kills PackageKit, or gvfsd, or the journal? A sluggish system to the point it's unusable is bad, but it's probably less bad than services silently dying. Anyway, both are bad.
But also, my laptop has NVMe. When swap is NVMe backed, it's tolerable. And zswap moderates the performance drop well enough that I get a heads up to make adjustments.
The one instance I've hit memory pressure and hit the power button? Workstation Live in a VM with 1500MB RAM (which is 50% more than the minimum on the download page), it has no swap setup, and I almost immediately get the OOM killer upon launching the installer. Whereas if I activate swap to even a hard drive, it's tolerable even if slow. Way better than that is 'systemctl start zram' which runs a zram.service item included with the anaconda package, and it sets up swap backed by a zram device. This service is enabled by default on netinstalls but not Lives. I don't know why.
We handle swap really, *really* badly. I'm inclined to think that if we want to keep it, this situation needs to dramatically improve to guarantee that desktop interactivity isn't compromised.
The anaconda zram.service works well for installation environments. I haven't tested it for day to day.
I think the IoT folks are making swap on zram enabled in their default installation. Makes sense, there's a good way to cook eMMC quickly and it's swap.
On Fri, Sep 14, 2018 at 10:43 PM, Chris Murphy lists@colorremedies.com wrote:
OOM killer might be worse if it's really arbitrary or non-configurable. What if it kills PackageKit, or gvfsd, or the journal? A sluggish system to the point it's unusable is bad, but it's probably less bad than services silently dying. Anyway, both are bad.
I suggest immediately powering off immediately before swapping is required. There will be horrible data loss, but it's better than the status quo (hanging until the user decides to manually power off regardless). We shouldn't be forcing users to decide for themselves when to press the power button.
It's a real shame.
Michael
On Sat, Sep 15, 2018 at 11:55 AM, mcatanzaro@gnome.org wrote:
On Fri, Sep 14, 2018 at 10:43 PM, Chris Murphy lists@colorremedies.com wrote:
OOM killer might be worse if it's really arbitrary or non-configurable. What if it kills PackageKit, or gvfsd, or the journal? A sluggish system to the point it's unusable is bad, but it's probably less bad than services silently dying. Anyway, both are bad.
I suggest immediately powering off immediately before swapping is required. There will be horrible data loss, but it's better than the status quo (hanging until the user decides to manually power off regardless). We shouldn't be forcing users to decide for themselves when to press the power button.
It's a real shame.
At this point you're just repeating this without saying if you've tried either zram or zswap. In my recent experience, I can't reproduce what you're talking about in a VM with a hard drive backed swap. That's slow as molasses but it does work, whereas OOM killer is pathological especially for an installation environment.
So in terms of priorities:
1. Enable zram.service by default on live installs. They're enabled on netinstall. I filed this request 6 months ago. https://bugzilla.redhat.com/show_bug.cgi?id=1562278
2. Up the memory minimum from 1G to 3G or 4G on getfedora.org. Even 2G is unreliable without some kind of swap, zram or drive backed.
Following the more immediate issues, could someone who knows more about zram vs zswap than I do, propose a feature for Fedora 30? Drop traditional swap, and enhance with zram or zswap? I don't see how you can just drop swap entirely, it's not a good enough stop gap for solving whatever the bigger problem is.
On Sat, Sep 15, 2018 at 12:17:47PM -0600, Chris Murphy wrote:
- Enable zram.service by default on live installs. They're enabled on
netinstall. I filed this request 6 months ago. https://bugzilla.redhat.com/show_bug.cgi?id=1562278
Chris, can you file a ticket for the Workstation WG in pagure so it doesn't get lost?
- Up the memory minimum from 1G to 3G or 4G on getfedora.org. Even 2G
is unreliable without some kind of swap, zram or drive backed.
Maybe this one too. I thought we had some discussion about this elsewhere already....
On Mon, 2018-09-17 at 10:11 -0400, Matthew Miller wrote:
On Sat, Sep 15, 2018 at 12:17:47PM -0600, Chris Murphy wrote:
- Enable zram.service by default on live installs. They're enabled on
netinstall. I filed this request 6 months ago. https://bugzilla.redhat.com/show_bug.cgi?id=1562278
Chris, can you file a ticket for the Workstation WG in pagure so it doesn't get lost?
- Up the memory minimum from 1G to 3G or 4G on getfedora.org. Even 2G
is unreliable without some kind of swap, zram or drive backed.
Maybe this one too. I thought we had some discussion about this elsewhere already....
If it's a listed minimum *for Workstation*, then fine. If we don't break it out by Edition, it gets hard, as you absolutely can run e.g. Server in 1GB or less feasibly, for some purposes. I used to run my IRC proxy VM with like half a gig of RAM as it just didn't need any more.
On Mon, Sep 17, 2018 at 8:11 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Sat, Sep 15, 2018 at 12:17:47PM -0600, Chris Murphy wrote:
- Enable zram.service by default on live installs. They're enabled on
netinstall. I filed this request 6 months ago. https://bugzilla.redhat.com/show_bug.cgi?id=1562278
Chris, can you file a ticket for the Workstation WG in pagure so it doesn't get lost?
- Up the memory minimum from 1G to 3G or 4G on getfedora.org. Even 2G
is unreliable without some kind of swap, zram or drive backed.
Maybe this one too. I thought we had some discussion about this elsewhere already....
Done.
This is more reliable than F28 which definitely was not reliable with even 2G RAM. But in any case 1G is not enough.
Also, with respect to hibernation and Windows, that does not exactly get a high user experience rating on HN. https://news.ycombinator.com/item?id=17991803
That tells me this may always be of questionable reliability, regardless of the resources thrown at it. And even if it's decently reliable, what are the resources to maintain it being decently reliable? What is hibernation reliability going to be on ARM? Even more variable?
So again, it makes me think of a way to make it easy for applications to save and restore state, out of the box, by default. But then go farther: they should be fairly crash safe. By that I mean no major corruption that prevents booting, application launch, or total user data loss. I might accept a minute of data loss, or perhaps even an hour, depending on the app. That can be implemented independently of arch, and with a few quibbles, independently of storage technology (lying hardware tends toward losing more data).
On Mon, Sep 17, 2018 at 12:32:19PM -0600, Chris Murphy wrote:
This is more reliable than F28 which definitely was not reliable with even 2G RAM. But in any case 1G is not enough.
Right; 4GB is the practical minimum on x86_64. 2GB is maybe doable on i386, but we don't recommend that, so.....
On Fri, Sep 14, 2018 at 05:47:56PM -0600, Chris Murphy wrote:
I'm pretty sure hibernate (suspend to disk) does not support files.
It does. We're currently missing some bits in upstream systemd to resume properly, but Ubuntu have them in their initramfs implementation. This should be easily fixable. See Lennart's email in the other thread for more details.
Zbyszek
So I'll be slightly curious if, with all the hibernation work Ubuntu is apparently doing, they end up going with partitions or if they've got some other trick up their sleeve, like teaching the bootloader how to find and resume hibernation from a file.
At least on Windows and macOS, the hibernation file is a separate thing from swapfiles. Maybe there's a good reason for this distinction, I'm not sure.
Hi,
On Fri, Sep 14, 2018 at 11:09 AM, Bastien Nocera bnocera@redhat.com wrote:
The kernel shouldn't be exposing features it can't reliably provide. Again, as I understand it, it's not even a hardware-supported situation, it can potentially fail on *any system* if the swap partition is filled up the wrong way, if i'm not mistaken.
There's multiple levels of "support". The kernel doesn't know if it has enough swap, this is checked by user-space, systemd in this case.
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
--Ray
On Fri, Sep 14, 2018 at 10:16 AM, Ray Strode rstrode@redhat.com wrote:
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
I think I agree with Ray... the Workstation kernel should not offer this at all unless it can be made reliable.
Michael
On Fr, 14.09.18 10:45, mcatanzaro@gnome.org (mcatanzaro@gnome.org) wrote:
On Fri, Sep 14, 2018 at 10:16 AM, Ray Strode rstrode@redhat.com wrote:
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
I think I agree with Ray... the Workstation kernel should not offer this at all unless it can be made reliable.
I tend to agree with this actually. I mean, I can understand why the GNOME folks don't want to expose an opt-in option for this, and want the lower layers to disable it. In fact I understand it so well, that I also would prefer if the lower layer from my own systemd PoV (i.e. the kernel) wouldn't offer us a feature that is known to be broken and unsupported.
Hence, I think that Fedora kernels should really turn off hibernation support entirely during compilation if there's no intention to really support it. This could be done either by compiling out the whole subsystem's code for it, or maybe with a kernel patch that adds a kernel cmdline or so, that must be specified to enable this code in the kernel.
For all other interfaces the kernel provides we assume that it works correctly if systemd can call into it. It *is* kinda weird if the hibernation APIs the kernel provides are made available but actually are not assumed to work properly.
Lennart
----- Original Message -----
On Fr, 14.09.18 10:45, mcatanzaro@gnome.org (mcatanzaro@gnome.org) wrote:
On Fri, Sep 14, 2018 at 10:16 AM, Ray Strode rstrode@redhat.com wrote:
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
I think I agree with Ray... the Workstation kernel should not offer this at all unless it can be made reliable.
I tend to agree with this actually. I mean, I can understand why the GNOME folks don't want to expose an opt-in option for this, and want the lower layers to disable it. In fact I understand it so well, that I also would prefer if the lower layer from my own systemd PoV (i.e. the kernel) wouldn't offer us a feature that is known to be broken and unsupported.
Hence, I think that Fedora kernels should really turn off hibernation support entirely during compilation if there's no intention to really support it. This could be done either by compiling out the whole subsystem's code for it, or maybe with a kernel patch that adds a kernel cmdline or so, that must be specified to enable this code in the kernel.
For all other interfaces the kernel provides we assume that it works correctly if systemd can call into it. It *is* kinda weird if the hibernation APIs the kernel provides are made available but actually are not assumed to work properly.
Strongly agreed. Having systemd disable it meant that it could be enabled and tested without either non-standard commands (whether a kernel option, a special systemd command, or a GNOME non-UI option), or needing a kernel recompilation.
There's a "nohibernate" kernel command-line option, but the code doesn't seem to be well thought out to allow changing the default value: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kern...
(declaration near the top of the file, and options handling at the bottom)
Maybe this is enough? -static int nohibernate; +static int nohibernate = 1;
On Mon, Sep 24, 2018 at 11:18:45AM -0400, Bastien Nocera wrote:
----- Original Message -----
On Fr, 14.09.18 10:45, mcatanzaro@gnome.org (mcatanzaro@gnome.org) wrote:
On Fri, Sep 14, 2018 at 10:16 AM, Ray Strode rstrode@redhat.com wrote:
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
I think I agree with Ray... the Workstation kernel should not offer this at all unless it can be made reliable.
I tend to agree with this actually. I mean, I can understand why the GNOME folks don't want to expose an opt-in option for this, and want the lower layers to disable it. In fact I understand it so well, that I also would prefer if the lower layer from my own systemd PoV (i.e. the kernel) wouldn't offer us a feature that is known to be broken and unsupported.
Hence, I think that Fedora kernels should really turn off hibernation support entirely during compilation if there's no intention to really support it. This could be done either by compiling out the whole subsystem's code for it, or maybe with a kernel patch that adds a kernel cmdline or so, that must be specified to enable this code in the kernel.
For all other interfaces the kernel provides we assume that it works correctly if systemd can call into it. It *is* kinda weird if the hibernation APIs the kernel provides are made available but actually are not assumed to work properly.
Strongly agreed. Having systemd disable it meant that it could be enabled and tested without either non-standard commands (whether a kernel option, a special systemd command, or a GNOME non-UI option), or needing a kernel recompilation.
Strongly *dis*agreed ;)
Hibernation works just fine for a lot of people, and even though it's not nice that we can't make it work for everybody, just disabling it outright would be significant disservice to those for whom it works and who make use of it.
Zbyszek
On Mo, 24.09.18 15:45, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
Hence, I think that Fedora kernels should really turn off hibernation support entirely during compilation if there's no intention to really support it. This could be done either by compiling out the whole subsystem's code for it, or maybe with a kernel patch that adds a kernel cmdline or so, that must be specified to enable this code in the kernel.
For all other interfaces the kernel provides we assume that it works correctly if systemd can call into it. It *is* kinda weird if the hibernation APIs the kernel provides are made available but actually are not assumed to work properly.
Strongly agreed. Having systemd disable it meant that it could be enabled and tested without either non-standard commands (whether a kernel option, a special systemd command, or a GNOME non-UI option), or needing a kernel recompilation.
Strongly *dis*agreed ;)
Hibernation works just fine for a lot of people, and even though it's not nice that we can't make it work for everybody, just disabling it outright would be significant disservice to those for whom it works and who make use of it.
Well, I suggested that there should be some kernel cmdline option or so to enable it if there's demand for it. i.e. if people specify "hibernatemeharder" on the kernel cmdline then they get current behaviour, but they are on their own if they do so...
I am just saying that when we play the game of "where to disable it by default" and there are three contenders "GNOME", "systemd" and "kernel", then it makes the most sense to to do so in the "kernel", i.e. the implementor and maintainer of the actual mechanism, so that is is comprehensively enabled or disabled, and not disabled half way and exposed in some codepaths still but not in others.
I mean, both the GNOME and the systemd developers would be fine with supporting hibernation in their *own* codepaths, and are pretty sure they can make their *own* codepaths safe and supportable. The problem is in the kernel side of things, and the assumption is that the kernel code is not supportable and not tested enough, and hence the Fedora kernel maintainers don't want to bless it. hence I think that's where this should be turned off, too.
I mean, adding a kernel cmdline option to your boot isn't too hard, and people who are technical enough to understand the implications of hibernation and are keen to test this should have no trouble in adding the kernel cmdline option themselves.
Lennart
Hi,
On 24-09-18 17:18, Bastien Nocera wrote:
----- Original Message -----
On Fr, 14.09.18 10:45, mcatanzaro@gnome.org (mcatanzaro@gnome.org) wrote:
On Fri, Sep 14, 2018 at 10:16 AM, Ray Strode rstrode@redhat.com wrote:
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
I think I agree with Ray... the Workstation kernel should not offer this at all unless it can be made reliable.
I tend to agree with this actually. I mean, I can understand why the GNOME folks don't want to expose an opt-in option for this, and want the lower layers to disable it. In fact I understand it so well, that I also would prefer if the lower layer from my own systemd PoV (i.e. the kernel) wouldn't offer us a feature that is known to be broken and unsupported.
Hence, I think that Fedora kernels should really turn off hibernation support entirely during compilation if there's no intention to really support it. This could be done either by compiling out the whole subsystem's code for it, or maybe with a kernel patch that adds a kernel cmdline or so, that must be specified to enable this code in the kernel.
For all other interfaces the kernel provides we assume that it works correctly if systemd can call into it. It *is* kinda weird if the hibernation APIs the kernel provides are made available but actually are not assumed to work properly.
Strongly agreed. Having systemd disable it meant that it could be enabled and tested without either non-standard commands (whether a kernel option, a special systemd command, or a GNOME non-UI option), or needing a kernel recompilation.
There's a "nohibernate" kernel command-line option, but the code doesn't seem to be well thought out to allow changing the default value: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kern...
(declaration near the top of the file, and options handling at the bottom)
Maybe this is enough? -static int nohibernate; +static int nohibernate = 1;
We will need a new commandline option to re-enable it, but yes otherwise I think that will be enough, setting this will make "cat /sys/power/disk" return "[disabled]".
Lennart, Zbyszek, does systemd handle this return value correctly and will CanHibernate and CanSuspendThenHibernate return false then ?
I guess so (but it would be good to have this confirmed).
I will also start a new thread for this on the fedora kernel list with the desktop list in the Cc to get input from the kernel team on this.
Regards,
Hans
On Sun, Sep 30, 2018 at 09:00:43PM +0200, Hans de Goede wrote:
We will need a new commandline option to re-enable it, but yes otherwise I think that will be enough, setting this will make "cat /sys/power/disk" return "[disabled]".
Lennart, Zbyszek, does systemd handle this return value correctly and will CanHibernate and CanSuspendThenHibernate return false then ?
Hi, [sorry for the late reply, I didn't notice this mail until now].
Yes, [disabled] causes systemd to think hibernation is not possible.
(Systemd only looks for "platform" and "shutdown" as verbs in that file when checking if hibernation is possible. This is easy enough to test: $ echo '[disabled]' > /tmp/disk $ sudo mount --bind /tmp/disk /sys/power/disk $ sudo SYSTEMD_LOG_LEVEL=debug build/test-sleep ... /= running system =/ Suspend configured and possible: yes Hibernation configured and possible: no Hybrid-sleep configured and possible: no Unable to hibernate system. Suspend-then-Hibernate configured and possible: no ... )
Zbyszek
----- Original Message -----
Hi,
On Fri, Sep 14, 2018 at 11:09 AM, Bastien Nocera bnocera@redhat.com wrote:
The kernel shouldn't be exposing features it can't reliably provide. Again, as I understand it, it's not even a hardware-supported situation, it can potentially fail on *any system* if the swap partition is filled up the wrong way, if i'm not mistaken.
There's multiple levels of "support". The kernel doesn't know if it has enough swap, this is checked by user-space, systemd in this case.
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
That's what this does: https://github.com/systemd/systemd/blob/master/src/shared/sleep-config.c#L24...
On Fri, Sep 14, 2018 at 9:16 AM, Ray Strode rstrode@redhat.com wrote:
Hi,
On Fri, Sep 14, 2018 at 11:09 AM, Bastien Nocera bnocera@redhat.com wrote:
The kernel shouldn't be exposing features it can't reliably provide. Again, as I understand it, it's not even a hardware-supported situation, it can potentially fail on *any system* if the swap partition is filled up the wrong way, if i'm not mistaken.
There's multiple levels of "support". The kernel doesn't know if it has enough swap, this is checked by user-space, systemd in this case.
But that's bonkers, there's no way systemd can know either. The only way to make this reliable is if the kernel has a dedicated hibernate partition the same size as ram that doesn't get used for anything but hibernate, right?
systemd knows what the kernel knows, cat /proc/meminfo - which includes what part of swap is used for swap, and what's needed for a hibernation image, and therefore if there's enough space on swap for both swap and hibernation to co-exist. I don't know if systemd uses any of the kernel test facilities in advance for things like whether all tasks are freezeable, whether any connected devices will prevent hibernation, and so on.
The used to be some unused code in the installer, regarding partitioning for hibernation support, and I vaguely recall for most configurations it wanted double the amount of memory because it was conceivable the hibernation image would be the same size as RAM, and also it was desirable to fully utilize swap. Seems like that could be 1.25x RAM, expecting to swap out no more than 1/4, and possibly need a 1:1 RAM to hibernation image ratio.
Anyway if you tell the kernel to hibernate, I think it tries to hibernate. Whereas systemd will advert to user space that hibernation isn't possible if it thinks it isn't possible, due to memory and swap space constraints.
On Thu, 2018-09-13 at 12:08 -0500, Justin Forbes wrote:
On Thu, Sep 13, 2018 at 12:00 PM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Sep 13, 2018 at 11:10 AM Hans de Goede hdegoede@redhat.com wrote:
Without an easy way for people to test this it will be broken for ever.
A feature like this needs to have an easy way to opt in, so that we can get people to test this and report issues (or success). So that we can improve the hw support over time until we feel comfortable to at least try to enable this by default.
It will be broken forever, since the kernel team can't support it, from what I hear. We should just remove hibernation support from the Fedora kernel. No point in haggling about an easy way to opt-in to a feature that is not supported.
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
If we are not going to support hibernation any time soon, then there is little reason to make the feature easily accessible to users.
So when considering that constraint, it does not seem like a great idea to allow users to configure hibernation (and suspend-then-hibernate) easily. It would be nice to have, but unfortunately it only makes sense if we are able commit the resources to fix issues that users run into.
Sounds to me that this means we should be turning off hibernation in systemd (I assume that is simple to do). In principle I am also fine with removing hibernation support from the kernel. But that seems like a much more invasive change and I suspect there may be a number of disappointed users.
Benjamin
It will be broken forever, since the kernel team can't support it, from what I hear. We should just remove hibernation support from the Fedora kernel. No point in haggling about an easy way to opt-in to a feature that is not supported.
Well, let's leave the decision on Fedora kernel developers :) From my point of view, having the hibernation support enabled in kernel doesn't hurt anything. GNOME shouldn't do it by default if it's not supported. If some user wants to hibernate, he should be able to. Disabling something in kernel entirely because GNOME chooses to do it by default anyway is not okay.
Also, I need to agree with Adam here, I don't see any disadvantages of using hybrid-sleep.
On Thu, Sep 13, 2018 at 4:40 PM Bastien Nocera bnocera@redhat.com wrote:
It's broken. systemd will use it when GNOME isn't involved,
I don't think so:
$ grep -E '(HandlePower|HandleLid)' /etc/systemd/logind.conf #HandlePowerKey=poweroff #HandleLidSwitch=suspend #HandleLidSwitchExternalPower=suspend #HandleLidSwitchDocked=ignore
Systemd defaults to poweroff or suspend, not to suspend-then-hibernate. Only gnome now defaults to suspend-then-hibernate.
therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
It doesn't just work, as explained by systemd and kernel folks. But it's an option you can use if you want (optionally, not default).
Disabling the support at the systemd level is as easy as masking a target. Somebody interested in using the feature just needs to unask a target, without needing to make changes to GNOME on top of that.
That means you have binary behavior, either or. That doesn't give people options to easily experiment on their existing hardware, or use the best approach at a given moment (i.e. suspend on monday to thursday, suspend-then-hibernate on friday).
This is what you want to do.
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
As I suggested, it doesn't need to be exposed in GUI. This is clearly experimental stuff that needs to get stabilized over time (hopefully), and it's completely fine if only power users can find it. But if GNOME doesn't allow even power users to use it, then we can hardly hope for improving the kernel and distro support in the future. It's those power users that generate bug reports that generate fixes.
----- Original Message -----
On Thu, Sep 13, 2018 at 4:40 PM Bastien Nocera < bnocera@redhat.com > wrote:
It's broken. systemd will use it when GNOME isn't involved,
I don't think so:
$ grep -E '(HandlePower|HandleLid)' /etc/systemd/logind.conf #HandlePowerKey=poweroff #HandleLidSwitch=suspend #HandleLidSwitchExternalPower=suspend #HandleLidSwitchDocked=ignore
Systemd defaults to poweroff or suspend, not to suspend-then-hibernate. Only gnome now defaults to suspend-then-hibernate.
systemctl suspend-then-hibernate will make use of it, whether or not it's a default.
therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
It doesn't just work, as explained by systemd and kernel folks. But it's an option you can use if you want (optionally, not default).
*should*. I know it doesn't work, otherwise we wouldn't be having that conversation, and I wouldn't be using a conditional :)
Disabling the support at the systemd level is as easy as masking a target. Somebody interested in using the feature just needs to unask a target, without needing to make changes to GNOME on top of that.
That means you have binary behavior, either or. That doesn't give people options to easily experiment on their existing hardware, or use the best approach at a given moment (i.e. suspend on monday to thursday, suspend-then-hibernate on friday).
It does, just mask and unmask the command. It doesn't require recompiling GNOME, and doesn't force GNOME to show options we know are broken, whether in Tweaks or Settings themselves.
This is what you want to do.
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
As I suggested, it doesn't need to be exposed in GUI. This is clearly experimental stuff that needs to get stabilized over time (hopefully), and it's completely fine if only power users can find it. But if GNOME doesn't allow even power users to use it, then we can hardly hope for improving the kernel and distro support in the future. It's those power users that generate bug reports that generate fixes.
systemd has an option to disable it at runtime. What's the problem with using that instead of adding more moving parts to GNOME?
On Thu, Sep 13, 2018 at 11:31:39AM -0400, Bastien Nocera wrote:
----- Original Message -----
On Thu, Sep 13, 2018 at 4:40 PM Bastien Nocera < bnocera@redhat.com > wrote:
It's broken. systemd will use it when GNOME isn't involved,
I don't think so:
$ grep -E '(HandlePower|HandleLid)' /etc/systemd/logind.conf #HandlePowerKey=poweroff #HandleLidSwitch=suspend #HandleLidSwitchExternalPower=suspend #HandleLidSwitchDocked=ignore
Systemd defaults to poweroff or suspend, not to suspend-then-hibernate. Only gnome now defaults to suspend-then-hibernate.
systemctl suspend-then-hibernate will make use of it, whether or not it's a default.
therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
It doesn't just work, as explained by systemd and kernel folks. But it's an option you can use if you want (optionally, not default).
*should*. I know it doesn't work, otherwise we wouldn't be having that conversation, and I wouldn't be using a conditional :)
Disabling the support at the systemd level is as easy as masking a target. Somebody interested in using the feature just needs to unask a target, without needing to make changes to GNOME on top of that.
That means you have binary behavior, either or. That doesn't give people options to easily experiment on their existing hardware, or use the best approach at a given moment (i.e. suspend on monday to thursday, suspend-then-hibernate on friday).
It does, just mask and unmask the command. It doesn't require recompiling GNOME, and doesn't force GNOME to show options we know are broken, whether in Tweaks or Settings themselves.
This is what you want to do.
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
As I suggested, it doesn't need to be exposed in GUI. This is clearly experimental stuff that needs to get stabilized over time (hopefully), and it's completely fine if only power users can find it. But if GNOME doesn't allow even power users to use it, then we can hardly hope for improving the kernel and distro support in the future. It's those power users that generate bug reports that generate fixes.
systemd has an option to disable it at runtime. What's the problem with using that instead of adding more moving parts to GNOME?
Hi,
[replying here, because I don't see a better point in the thread]
IMHO it is better to disable hibernation in systemd if we know it cannot work rather than disable s2h permanently in gnome. In particular, it is fairly easy to tweak systemd to understand the 'noresume' parameter and notice the lack of 'resume=' (Long term we want to make hibernation work without resume=, but until then.) I'll try to get this ready before F29 final.
That should solve the case of "configuration" issues, and will leave us only with those cases where the kernel drivers have issues.
Zbyszek
Hi,
On 09/14/2018 06:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Sep 13, 2018 at 11:31:39AM -0400, Bastien Nocera wrote:
----- Original Message -----
On Thu, Sep 13, 2018 at 4:40 PM Bastien Nocera < bnocera@redhat.com > wrote:
It's broken. systemd will use it when GNOME isn't involved,
I don't think so:
$ grep -E '(HandlePower|HandleLid)' /etc/systemd/logind.conf #HandlePowerKey=poweroff #HandleLidSwitch=suspend #HandleLidSwitchExternalPower=suspend #HandleLidSwitchDocked=ignore
Systemd defaults to poweroff or suspend, not to suspend-then-hibernate. Only gnome now defaults to suspend-then-hibernate.
systemctl suspend-then-hibernate will make use of it, whether or not it's a default.
therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
It doesn't just work, as explained by systemd and kernel folks. But it's an option you can use if you want (optionally, not default).
*should*. I know it doesn't work, otherwise we wouldn't be having that conversation, and I wouldn't be using a conditional :)
Disabling the support at the systemd level is as easy as masking a target. Somebody interested in using the feature just needs to unask a target, without needing to make changes to GNOME on top of that.
That means you have binary behavior, either or. That doesn't give people options to easily experiment on their existing hardware, or use the best approach at a given moment (i.e. suspend on monday to thursday, suspend-then-hibernate on friday).
It does, just mask and unmask the command. It doesn't require recompiling GNOME, and doesn't force GNOME to show options we know are broken, whether in Tweaks or Settings themselves.
This is what you want to do.
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
As I suggested, it doesn't need to be exposed in GUI. This is clearly experimental stuff that needs to get stabilized over time (hopefully), and it's completely fine if only power users can find it. But if GNOME doesn't allow even power users to use it, then we can hardly hope for improving the kernel and distro support in the future. It's those power users that generate bug reports that generate fixes.
systemd has an option to disable it at runtime. What's the problem with using that instead of adding more moving parts to GNOME?
Hi,
[replying here, because I don't see a better point in the thread]
IMHO it is better to disable hibernation in systemd if we know it cannot work rather than disable s2h permanently in gnome. In particular, it is fairly easy to tweak systemd to understand the 'noresume' parameter and notice the lack of 'resume=' (Long term we want to make hibernation work without resume=, but until then.) I'll try to get this ready before F29 final.
That should solve the case of "configuration" issues, and will leave us only with those cases where the kernel drivers have issues.
Although it would be good to make sure that systemd does not advertise hibernate or hybrid support when there are configuration issues, that is not enough.
There will be many driver issues and we simply cannot have F29 using hibernate by default anywhere.
So if systemd is going to keep advertising support on systems where the config is ok for it, then we need to patch GNOME to not use it (by default).
Would it be possible to stop systemd from having hibernate support completely, with some (simple) way for users who want to use hhibernate to disable this behavior by changing the config ?
Note I'm not saying that that is the best solution, I just wonder if it is doable and what your take is on solving this that way ?
Regards,
Hans
On Fri, Sep 14, 2018 at 11:36 AM, Hans de Goede hdegoede@redhat.com wrote:
Would it be possible to stop systemd from having hibernate support completely, with some (simple) way for users who want to use hhibernate to disable this behavior by changing the config ?
mask suspend-then-hibernate.target
That seems sane to me. A nicer approach would be to add a toggle to tweak tool or dconf, under an experimental area or warning in parenthesis.
On Fri, 2018-09-14 at 16:54 +0000, Zbigniew Jędrzejewski-Szmek wrote:
IMHO it is better to disable hibernation in systemd if we know it cannot work rather than disable s2h permanently in gnome. In particular, it is fairly easy to tweak systemd to understand the 'noresume' parameter and notice the lack of 'resume=' (Long term we want to make hibernation work without resume=, but until then.) I'll try to get this ready before F29 final.
That should solve the case of "configuration" issues, and will leave us only with those cases where the kernel drivers have issues.
Well, it was suggested upthread that even if resume= is set, swap could well be too small. Per its comments, for instance, anaconda certainly does not ensure that swap size is larger than RAM size:
# the succeeding if-statement implements the following formula for # suggested swap size. # # swap(mem) = 2 * mem, if mem < 2 GiB # = mem, if 2 GiB <= mem < 8 GiB # = mem / 2, if 8 GIB <= mem < 64 GiB # = 4 GiB, if mem >= 64 GiB
it's going to be exactly equal to memory size or smaller than memory size on almost all modern systems, according to that at least.
On Fri, Sep 14, 2018 at 12:24:18PM -0700, Adam Williamson wrote:
On Fri, 2018-09-14 at 16:54 +0000, Zbigniew Jędrzejewski-Szmek wrote:
IMHO it is better to disable hibernation in systemd if we know it cannot work rather than disable s2h permanently in gnome. In particular, it is fairly easy to tweak systemd to understand the 'noresume' parameter and notice the lack of 'resume=' (Long term we want to make hibernation work without resume=, but until then.) I'll try to get this ready before F29 final.
That should solve the case of "configuration" issues, and will leave us only with those cases where the kernel drivers have issues.
Well, it was suggested upthread that even if resume= is set, swap could well be too small. Per its comments, for instance, anaconda certainly does not ensure that swap size is larger than RAM size:
# the succeeding if-statement implements the following formula for # suggested swap size. # # swap(mem) = 2 * mem, if mem < 2 GiB # = mem, if 2 GiB <= mem < 8 GiB # = mem / 2, if 8 GIB <= mem < 64 GiB # = 4 GiB, if mem >= 64 GiBit's going to be exactly equal to memory size or smaller than memory size on almost all modern systems, according to that at least.
Systemd compares the amount of memory used to the available swap space and does not offer hibernation if there isn't enough. I haven't seen reports that this calculation is not done properly. In other words, systemd cannot always offer hibernation, but when it does, is shouldn't fail (at least because of memory issues, other problems are still possible of course).
Zbyszek
hi,
On Fri, Sep 14, 2018, 6:30 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Systemd compares the amount of memory used to the available swap space and does not offer hibernation if there isn't enough. I haven't seen reports that this calculation is not done properly.
I was told years ago that there's no way userspace can reliably know, and even if we activated a dedicated bigger-than-memory sized swap partition immediately before hibernate started it could still fail. maybe things have improved since then, or maybe it wasn't accurate information. dunno.
Ray
On Fri, Sep 14, 2018 at 08:07:35PM -0400, Ray Strode wrote:
hi,
On Fri, Sep 14, 2018, 6:30 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Systemd compares the amount of memory used to the available swap space and does not offer hibernation if there isn't enough. I haven't seen reports that this calculation is not done properly.
I was told years ago that there's no way userspace can reliably know, and even if we activated a dedicated bigger-than-memory sized swap partition immediately before hibernate started it could still fail. maybe things have improved since then, or maybe it wasn't accurate information. dunno.
Sure, this is correct. But the chances of that happening are fairly low, so among all the problems we have, this seems like a relatively minor issue.
Zbyszek
On Fri, Sep 14, 2018 at 08:07:35PM -0400, Ray Strode wrote:
Systemd compares the amount of memory used to the available swap space and does not offer hibernation if there isn't enough. I haven't seen reports that this calculation is not done properly.
I was told years ago that there's no way userspace can reliably know, and even if we activated a dedicated bigger-than-memory sized swap partition immediately before hibernate started it could still fail. maybe things have improved since then, or maybe it wasn't accurate information. dunno.
I think the issue is that it's it's _possible_ that a out-of-control process could suddenly eat up a bunch of memory and go to swap right at the wrong time. If there's enough space, this is unlikely in practical use. I'm not super worried, because realistically that out-of-control processes and runaway swap thrashing was going to take your system down or at the very least trigger OOM killing *anyway*.
On Mon, Sep 17, 2018 at 9:07 AM, Matthew Miller mattdm@fedoraproject.org wrote:
I think the issue is that it's it's _possible_ that a out-of-control process could suddenly eat up a bunch of memory and go to swap right at the wrong time. If there's enough space, this is unlikely in practical use. I'm not super worried, because realistically that out-of-control processes and runaway swap thrashing was going to take your system down or at the very least trigger OOM killing *anyway*.
Matthew, this happens *all the time* to me and to other developers I work with when building software. All the time. I fine-tune my ninjaargs to figure out the highest -j I can use when building without killing my desktop. We shouldn't have to do this. We're not talking about out of control processes, we're talking about running make or ninja exactly as designed: it's expected to spawn a huge number of GCC subprocesses (4, 8, 32...), each one will want 1-2 GB of RAM... the Fedora desktop should remain smooth and performant under this load and throttle ninja as needed, not freeze up.
If zram or zswap will help such that the desktop doesn't freeze up, then great, let's try that.
Michael
On Mon, Sep 17, 2018 at 11:19:39AM -0500, mcatanzaro@gnome.org wrote:
I'm not super worried, because realistically that out-of-control processes and runaway swap thrashing was going to take your system down or at the very least trigger OOM killing *anyway*.
Matthew, this happens *all the time* to me and to other developers I work with when building software. All the time. I fine-tune my ninjaargs to figure out the highest -j I can use when building without killing my desktop. We shouldn't have to do this. We're not talking about out of control processes, we're talking about running make or ninja exactly as designed: it's expected to spawn a huge number of GCC subprocesses (4, 8, 32...), each one will want 1-2 GB of RAM... the Fedora desktop should remain smooth and performant under this load and throttle ninja as needed, not freeze up.
Sorry if I wasn't clear: I didn't mean that this wasn't a problem. I meant that given how badly this already sucks, the possibility of it happening right when hibernating is ... how to say... what's the opposite of icing on the cake? Sure, your system may not hibernate properly, but at that point it was already doomed anyway.
On Mon, Sep 17, 2018 at 10:19 AM, mcatanzaro@gnome.org wrote:
On Mon, Sep 17, 2018 at 9:07 AM, Matthew Miller mattdm@fedoraproject.org wrote:
I think the issue is that it's it's _possible_ that a out-of-control process could suddenly eat up a bunch of memory and go to swap right at the wrong time. If there's enough space, this is unlikely in practical use. I'm not super worried, because realistically that out-of-control processes and runaway swap thrashing was going to take your system down or at the very least trigger OOM killing *anyway*.
Matthew, this happens *all the time* to me and to other developers I work with when building software. All the time. I fine-tune my ninjaargs to figure out the highest -j I can use when building without killing my desktop. We shouldn't have to do this. We're not talking about out of control processes, we're talking about running make or ninja exactly as designed: it's expected to spawn a huge number of GCC subprocesses (4, 8, 32...), each one will want 1-2 GB of RAM... the Fedora desktop should remain smooth and performant under this load and throttle ninja as needed, not freeze up.
If zram or zswap will help such that the desktop doesn't freeze up, then great, let's try that.
[root@f29h ~]# cat /proc/sys/vm/swappiness 60
This is now widely regarded as sabotage, because it's simply too aggressive for the amount of RAM we have these days compared to 4MB of RAM. Upstream is unlikely to change it, they've been beaten over the head for years about it.
Try
# echo 1 > /proc/sys/vm/swappiness
Now do whatever normally blows things up, and report back. I'm kinda curious. If the problem is simply too aggressive swapping, then neither zram nor zswap will make that much of a difference (it will moderate the transition to depending on swap, but once it's pathological, you'll still be screwed if this is really just a workload for which swappiness 60 is flat out bad).
On Thu, Sep 20, 2018 at 11:24 AM, Chris Murphy lists@colorremedies.com wrote:
[root@f29h ~]# cat /proc/sys/vm/swappiness 60
This is now widely regarded as sabotage, because it's simply too aggressive for the amount of RAM we have these days compared to 4MB of RAM. Upstream is unlikely to change it, they've been beaten over the head for years about it.
Try
# echo 1 > /proc/sys/vm/swappiness
I've seen suggestions to use 0 as well.
Now do whatever normally blows things up, and report back. I'm kinda curious. If the problem is simply too aggressive swapping, then neither zram nor zswap will make that much of a difference (it will moderate the transition to depending on swap, but once it's pathological, you'll still be screwed if this is really just a workload for which swappiness 60 is flat out bad).
I'll try it when I can.
How do we change this default for Workstation? Is it a kernel tunable?
Michael
On Thu, Sep 20, 2018 at 10:34 AM, mcatanzaro@gnome.org wrote:
On Thu, Sep 20, 2018 at 11:24 AM, Chris Murphy lists@colorremedies.com wrote:
[root@f29h ~]# cat /proc/sys/vm/swappiness 60
This is now widely regarded as sabotage, because it's simply too aggressive for the amount of RAM we have these days compared to 4MB of RAM. Upstream is unlikely to change it, they've been beaten over the head for years about it.
Try
# echo 1 > /proc/sys/vm/swappiness
I've seen suggestions to use 0 as well.
I would try 1. I'm pretty sure 0 will just disable swap which doesn't really help us figure out if it's just the swappiness setting being too aggressive.
I'll try it when I can.
How do we change this default for Workstation? Is it a kernel tunable?
Yes. I'm not sure if the preferred way is to use e.g. /etc/tmpfiles.d/workstationswappiness.conf containing an appropriate comment and the line:
w /proc/sys/vm/swappiness - - - - 1
Or since Fedora is not the user, probably follow this advice:
[root@f29h ~]# cat /etc/sysctl.conf # sysctl settings are defined through files in # /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/. # # Vendors settings live in /usr/lib/sysctl.d/. # To override a whole file, create a new file with the same in # /etc/sysctl.d/ and put new settings there. To override # only specific settings, add a file with a lexically later # name in /etc/sysctl.d/ and put new settings there. # # For more information, see sysctl.conf(5) and sysctl.d(5).
So maybe it'd go in /usr/lib/sysctl.d and takes the form
vm.swappiness = 1
Maybe it should be 10 instead, as a compromise. But I wanna know first if 1 is gonna make things sane, then see if they're still sane at 10 with zswap or zram. And then there's some real world data to go with the theory, and write up a summary for the kernel list and see what they think about the idea.
I actually think it's very possibly a good idea across the board for all editions if it ends up being 10. This is even recommended by Red Hat for database use cases. And compiling the way you're describing it, is something like a database operation but then also you have a bunch of user space apps and the GUI and if any of that gets swapped out well yeah, performance from the user's perspective is gonna be total shit. Whereas if that isn't being swapped out, what it does is limits how much memory your application can use for compiling, which will make the compiling slower, but I have no idea by how much. At the least though, if this is in fact part or all of the problem, the user doesn't lose control and isn't forcing power off on their system and isn't getting pissed off. :-D Instead, maybe they grumble about how they need more RAM, which is the right response.
On Sult 20, 2018 aig 10:59:44m -0600, sgrìobh Chris Murphy:
On Thu, Sep 20, 2018 at 10:34 AM, mcatanzaro@gnome.org wrote:
I've seen suggestions to use 0 as well.
I would try 1. I'm pretty sure 0 will just disable swap which doesn't really help us figure out if it's just the swappiness setting being too aggressive.
Yeah, 0 essentially disables swap. Go with 1.
-- Tapadh leabh, Dulaney.
On Thu, Sep 20, 2018 at 12:04:14PM -0700, Dulaney wrote:
On Sult 20, 2018 aig 10:59:44m -0600, sgrìobh Chris Murphy:
On Thu, Sep 20, 2018 at 10:34 AM, mcatanzaro@gnome.org wrote:
I've seen suggestions to use 0 as well.
I would try 1. I'm pretty sure 0 will just disable swap which doesn't really help us figure out if it's just the swappiness setting being too aggressive.
Yeah, 0 essentially disables swap. Go with 1.
vm.swapiness doesn't really solve the problem of "we need large swap so hibernation always works, but we don't want to use that swap for actual swapping because that'd be slow as hell". I think we need a new kernel setting "how much swap to use for swap", and then we could set that to 1 GB or 20% of RAM. Essentially the idea is to force oom even if there's free swap. ... After spelling this out, I think this setting might already exist: memory.swap.max in cgroups v2. IIRC, it is not available on v1, which is still the default in Fedora (*). Also, it doesn't exist for the root slice, but only for non-root slices. But setting it for system.slice, machine.slice, and user.slice each might get us a long way. I think setting swap.max to some reasonable value by default (e.g. using a systemd generator that look at the overall system characteristics) might be an interesting solution to the swap problems described so vividly in this thread.
Zbyszek
(*) Or the least the memory controller is too heavy to enable by default?
On Do, 20.09.18 21:53, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
On Thu, Sep 20, 2018 at 12:04:14PM -0700, Dulaney wrote:
On Sult 20, 2018 aig 10:59:44m -0600, sgrìobh Chris Murphy:
On Thu, Sep 20, 2018 at 10:34 AM, mcatanzaro@gnome.org wrote:
I've seen suggestions to use 0 as well.
I would try 1. I'm pretty sure 0 will just disable swap which doesn't really help us figure out if it's just the swappiness setting being too aggressive.
Yeah, 0 essentially disables swap. Go with 1.
vm.swapiness doesn't really solve the problem of "we need large swap so hibernation always works, but we don't want to use that swap for actual swapping because that'd be slow as hell".
We could in theory also activate the swap partition only when we need it for hibernation, and deactivate it after hibernation, i.e. enclose the actual hibernation operation with a tight swapon/swapoff.
That said, this feels all a bit too much like superficial tweaking to me. If Linux swap behaviour sucks it's really up to the kernel folks to fix it, and we shouldn't add new infrastructure around it in userspace that tries to make it less bad without touching the actual problems with it.
Lennart
On Mon, Sep 24, 2018 at 10:48 AM Lennart Poettering mzerqung@0pointer.de wrote:
That said, this feels all a bit too much like superficial tweaking to me. If Linux swap behaviour sucks it's really up to the kernel folks to fix it, and we shouldn't add new infrastructure around it in userspace that tries to make it less bad without touching the actual problems with it.
I agree.
On Thu, Sep 20, 2018 at 11:34 AM, mcatanzaro@gnome.org wrote:
I'll try it when I can.
Didn't seem to make much difference to me, when building WebKit without -j2 (I normally use -j2 to ensure it doesn't freeze my Fedora). The desktop becomes super sluggish as soon as it starts using swap. then froze after a couple of minutes when it was at around 5 GiB of swap. If it makes things better, great, but it's no solution.
I also wonder about the I/O scheduler. Ubuntu is using the deadline scheduler because it reportedly is better for interactivity, and that is what we want to optimize Workstation for. Perhaps it handles these situations better. Dunno.
Michael
On Thu, 2018-09-20 at 12:49 -0500, mcatanzaro@gnome.org wrote:
On Thu, Sep 20, 2018 at 11:34 AM, mcatanzaro@gnome.org wrote:
I'll try it when I can.
Didn't seem to make much difference to me, when building WebKit without -j2 (I normally use -j2 to ensure it doesn't freeze my Fedora). The desktop becomes super sluggish as soon as it starts using swap. then froze after a couple of minutes when it was at around 5 GiB of swap. If it makes things better, great, but it's no solution.
I think 'swappiness' is about *how likely the kernel is to use swap*, not what happens once it definitely is using swap. With high values it can actually decide to use swap even if some real memory is still free, I think.
If you're running a compile that needs more memory than is actually available as physical RAM, there's really no option there, whatever any config values are set to, the kernel's gonna have to go into swap space for it.
https://en.wikipedia.org/wiki/Swappiness
On Thu, Sep 20, 2018 at 11:49 AM, mcatanzaro@gnome.org wrote:
On Thu, Sep 20, 2018 at 11:34 AM, mcatanzaro@gnome.org wrote:
I'll try it when I can.
Didn't seem to make much difference to me, when building WebKit without -j2 (I normally use -j2 to ensure it doesn't freeze my Fedora). The desktop becomes super sluggish as soon as it starts using swap. then froze after a couple of minutes when it was at around 5 GiB of swap. If it makes things better, great, but it's no solution.
I also wonder about the I/O scheduler. Ubuntu is using the deadline scheduler because it reportedly is better for interactivity, and that is what we want to optimize Workstation for. Perhaps it handles these situations better. Dunno.
deadline favors reads over writes; I'm also not certain it's involved in the swap code path.
5GiB is a lot of swap. I don't see how disabling swap is going to make this better if the system is under that much memory pressure by the application, unless ... the application is giving the kernel unreasonable page eviction hinting to the kernel? zram could plausibly get you 1.5x to 2x RAM since it's compressing with LZ4. If nothing else that'd be an interesting zram stress test.
I've got only 8G on a laptop that I routinely use with -j4 to compile the kernel and it never uses swap.
At this point, the subject is better asked on devel@ as a separate thread and solicit some advice on what's going on (or how to find out what's going on), and whether there's a work around. If you totally disable swap, is this behavior any better?
IMHO it is better to disable hibernation in systemd if we know it cannot work rather than disable s2h permanently in gnome. In particular, it is fairly easy to tweak systemd to understand the 'noresume' parameter and notice the lack of 'resume=' (Long term we want to make hibernation work without resume=, but until then.) I'll try to get this ready before F29 final.
That should solve the case of "configuration" issues, and will leave us only with those cases where the kernel drivers have issues.
Well, it was suggested upthread that even if resume= is set, swap could well be too small. Per its comments, for instance, anaconda certainly does not ensure that swap size is larger than RAM size:
# the succeeding if-statement implements the following formula for # suggested swap size. # # swap(mem) = 2 * mem, if mem < 2 GiB # = mem, if 2 GiB <= mem < 8 GiB # = mem / 2, if 8 GIB <= mem < 64 GiB # = 4 GiB, if mem >= 64 GiBit's going to be exactly equal to memory size or smaller than memory size on almost all modern systems, according to that at least.
I also wonder how it detects if zram is being used for swap.
Hi,
On Thu, 2018-09-13 at 10:40 -0400, Bastien Nocera wrote:
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
We already have the "Hibernate" option in gnome-control-center. And, to be honest, the main issue with enabling SuspendThenHibernate is hibernation itself not working in the first place.
So, I don't really see that we would be adding a lot of extra confusion to the control-panel.
Benjamin
----- Original Message -----
Hi,
On Thu, 2018-09-13 at 10:40 -0400, Bastien Nocera wrote:
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
We already have the "Hibernate" option in gnome-control-center. And, to be honest, the main issue with enabling SuspendThenHibernate is hibernation itself not working in the first place.
But why don't we disable those at the systemd level then? If we know they're broken, they will be broken for every use case. Disable it in systemd in Fedora, the "Can*" functions in systemd return false, and the options don't appear in GNOME.
So, I don't really see that we would be adding a lot of extra confusion to the control-panel.
It would get added to the configuration panel, and be selectable, and be broken. It doesn't make anything better, it just shifts the blame to the user who's supposed to know that hibernate is broken.
On Thu, 2018-09-13 at 16:25 +0200, Hans de Goede wrote:
Hi,
On 13-09-18 16:16, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
My reaction to Bastien and yours crossed, right gsd-power has no configuration option now. What I'm suggesting is, that since some people want this to be opt-in, we add such a configuration option.
This really is a policy decision and as such belongs in GNOME IMHO systemd simply provides a mechanism for this and the availability call it has is to indicate if the hardware can support this at all (with no guarantees about this working).
I do see how this is a policy decision in a way. However, the main reason for me to *not* enable suspend-then-hibernate is that we consider hibernation to be unstable/unsupported in the first place. And if we consider hibernate non-functional, then it could be sane to disable hibernation in the first place.
That said, we are hitting this issue only because the feature was added to systemd and gnome-settings-daemon and also enabled by default. Adding an option to gnome-settings-daemon, would be a functional workaround and would also allow users to easily enable it for testing purposes.
So, Hans' suggestion to add a gsd-power option may actually be the best solution. I think that being able make it easily configurable by users is the main advantage of this approach.
Either way we need to do something about this for F29.
Agreed.
Benjamin
On Thu, 2018-09-13 at 16:16 +0200, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
Continuing the slight tangent from earlier - why was this preferred to hybrid-sleep, given that systemd apparently implements hybrid-sleep? Off the top of my head I can think of only one tiny benefit of suspend- then-hibernate over hybrid-sleep: after 3 hours it doesn't drain the battery at all any more. Is that really a big enough benefit to outweigh the drawback of *always* requiring the slower, much-more- likely-to-fail 'resume-from-hibernation' behaviour after 3 hours or more?
On Thu, 2018-09-13 at 16:55 -0700, Adam Williamson wrote:
On Thu, 2018-09-13 at 16:16 +0200, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
Continuing the slight tangent from earlier - why was this preferred to hybrid-sleep, given that systemd apparently implements hybrid-sleep? Off the top of my head I can think of only one tiny benefit of suspend- then-hibernate over hybrid-sleep: after 3 hours it doesn't drain the battery at all any more. Is that really a big enough benefit to outweigh the drawback of *always* requiring the slower, much-more- likely-to-fail 'resume-from-hibernation' behaviour after 3 hours or more?
hybrid-sleep would also seem to address the "hibernate *sometimes* works, but not often enough for us to support it or default to it" problem quite nicely...because it only uses hibernation as a last resort, when power is completely drained so resume from sleep is no longer possible. Think about it this way, we have three choices:
1) simple 'suspend': always uses the more reliable mechanism *unless* you lose power, at which point you have DEFINITELY lost your system state
2) suspend-then-hibernate: always uses the more reliable mechanism for three hours, then *ALWAYS* falls back to the less reliable mechanism. Will be substantially more risky than 1) for any case where the system sleeps for more than 3 hours, but retains power. Will only be safer than 1) when the system sleeps for more than 3 hours, then loses power.
3) hybrid-sleep: always uses the more reliable mechanism *unless* you lose power, at which point it gives the less reliable mechanism a shot. If it works, great! If it doesn't, you are no worse off than under 1). 2) has no advantages over 3) either, so far as I can see, except that if you sleep for a really long time and 'hibernate' actually happens to work on your system, maybe you have a little more battery life left when you resume.
I don't see how 3) isn't the winner there, assuming the implementation is good.
Hi,
it depends on how you look at it. You are looking at it from the point of having the largest fail safety, then yes. However, as I see this, it is mostly about preventing battery drain. i.e. enable users to suspend their machines for a day or two and continue working on battery afterwards.
With this criteria, you get: 1. simple 'suspend': - High battery drain - Fails on power loss + Fast suspend + Fast resume
2. suspend-then-hibernate: + Low battery drain + No failure on power loss + Fast suspend + Fast resume
3. hybrid-suspend: - High battery drain + No failure on power loss - Slow suspend + Fast resume
And with this criteria suspend-then-hibernate clearly wins.
You potentially get some more complications with s2i (suspend to idle) in the future. One could for example leave the WiFi and TCP/IP connections established for a period of time during suspend (but still freeze userspace otherwise).
Benjamin
On Thu, 2018-09-13 at 17:03 -0700, Adam Williamson wrote:
On Thu, 2018-09-13 at 16:55 -0700, Adam Williamson wrote:
On Thu, 2018-09-13 at 16:16 +0200, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
Continuing the slight tangent from earlier - why was this preferred to hybrid-sleep, given that systemd apparently implements hybrid-sleep? Off the top of my head I can think of only one tiny benefit of suspend- then-hibernate over hybrid-sleep: after 3 hours it doesn't drain the battery at all any more. Is that really a big enough benefit to outweigh the drawback of *always* requiring the slower, much-more- likely-to-fail 'resume-from-hibernation' behaviour after 3 hours or more?
hybrid-sleep would also seem to address the "hibernate *sometimes* works, but not often enough for us to support it or default to it" problem quite nicely...because it only uses hibernation as a last resort, when power is completely drained so resume from sleep is no longer possible. Think about it this way, we have three choices:
- simple 'suspend': always uses the more reliable mechanism *unless*
you lose power, at which point you have DEFINITELY lost your system state
- suspend-then-hibernate: always uses the more reliable mechanism for
three hours, then *ALWAYS* falls back to the less reliable mechanism. Will be substantially more risky than 1) for any case where the system sleeps for more than 3 hours, but retains power. Will only be safer than 1) when the system sleeps for more than 3 hours, then loses power.
- hybrid-sleep: always uses the more reliable mechanism *unless* you
lose power, at which point it gives the less reliable mechanism a shot. If it works, great! If it doesn't, you are no worse off than under 1). 2) has no advantages over 3) either, so far as I can see, except that if you sleep for a really long time and 'hibernate' actually happens to work on your system, maybe you have a little more battery life left when you resume.
I don't see how 3) isn't the winner there, assuming the implementation is good. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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 Fri, Sep 14, 2018 at 09:34:14AM +0200, Benjamin Berg wrote:
it depends on how you look at it. You are looking at it from the point of having the largest fail safety, then yes. However, as I see this, it is mostly about preventing battery drain. i.e. enable users to suspend their machines for a day or two and continue working on battery afterwards.
I know Matthias and others are very passionate about making an opinionated choice and not offering a user option for this, but to me this really seems like one of the things where there are several very reasonable workflows that different people in our target audience will want. I just can't see a way of getting this right for everyone with a one-size-fits-all approach.
To me personally, the case you give is basically irrelevant to my daily life. I would be very frustrated by the costs it puts on me. Conversely, I can see someone who *does* want to work the way you describe be frustrated by what works for me.
I don't think we want a sea of options, but there are some cases like this where offering smart choices seems like the best thing to do for users.
Hi,
On 13-09-18 16:06, Bastien Nocera wrote:
----- Original Message -----
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Various people have suggested in the discussion to make this opt-in rather then completely disable it.
Opt-in would mean making this an option in the control-center's power-settings pane, which clearly makes this something to fix on the GNOME side.
This is a policy decision, what you are suggesting is simply completely disabling the mechanism provided by systemd that seems wrong.
Regards,
Hans
Hi,
The issue comes up now, because systemd and gnome-settings-daemon now implement the SuspendThenHibernate option, which will automatically hibernate after 3 hours. This is a major change in policy. It is in particular problematic, as it means that we end up using hibernation by default, which is (currently) unsupported and likely to result in data loss for some users.
I believe the following options were proposed: 1. Create a setting for gnome-settings-daemon to disable the SuspendThenHibernate feature and simply always use Suspend. Expose this in gnome-control-center. 2. Disable Hibernate (and SuspendThenHibernate) in systemd(-logind) 3. Disable hibernation support in the Fedora kernel 4. Disable SuspendThenHibernate and switch to hybrid suspend
So, as I see it: 1. Adding a GNOME setting + Easy to configure by users - Requires Fedora specific gnome-settings-daemon and gnome-control-center patches and UI changes - Looks like hibernation and suspend-then-hibernate is supported, while we do not support it
2. Disable hibernation (and suspend-then-hibernate) in systemd + Also removed "Hibernate" option from "Power Button action" in gnome-control-center (as we don't support it) + Easy enough to enable for testing purposes + Users get the more desirable suspend-then-hibernate policy by default if enabled in systemd. * Note that I am unsure if this is currently easily possible. A systemd patch may be necessary to make this configurable.
3. Hibernation disabled in Kernel + Prevents this issue completely + Makes it very clear we do not support hibernate - Makes it hard to test hibernation - Probably makes some existing users rather unhappy * This would be a decision for the kernel team to make.
4. Prefer hybrid suspend (rather than SuspendThenHibernate) + Might result in some extra testing exposure for hibernation + Added feature to not loose data when battery runs out - No advantage with regard to battery runtime (suspend-then-hibernate is all about power saving) - Is a also a bigger change in default policy in my view - Makes suspend operation much slower * This might be easiest to implement in systemd, not sure though i.e. disable SuspendThenHibernate and change default Suspend action
I hope that this summarises the discussion sufficiently and I didn't miss important bits.
Benjamin
On Thu, 2018-09-13 at 15:45 +0200, Hans de Goede wrote:
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
Regards,
Hans
My take on this is that we want the feature, but not as a 'try to see if it works' feature. So my suggestion is as follows: 1) We disable it by default 2) We develop some kind of whitelisting system to allow us to enable this on systems we know it works (maybe tie it into the whitelisting system Hans has created for other power saving features?) 3) Once we have this is place we can discuss doing a UI to allow people to tweak behaviour of this, like they do on MacOS X, but it would be a UI that is only visible for people on whitelisted systems to tweak between known behaviours, not a 'try to turn this on to potentially break your system' UI.
Christian
On Fri, Sep 14, 2018 at 7:34 AM Benjamin Berg bberg@redhat.com wrote:
Hi,
The issue comes up now, because systemd and gnome-settings-daemon now implement the SuspendThenHibernate option, which will automatically hibernate after 3 hours. This is a major change in policy. It is in particular problematic, as it means that we end up using hibernation by default, which is (currently) unsupported and likely to result in data loss for some users.
I believe the following options were proposed:
- Create a setting for gnome-settings-daemon to disable the SuspendThenHibernate feature and simply always use Suspend. Expose this in gnome-control-center.
- Disable Hibernate (and SuspendThenHibernate) in systemd(-logind)
- Disable hibernation support in the Fedora kernel
- Disable SuspendThenHibernate and switch to hybrid suspend
So, as I see it:
- Adding a GNOME setting
- Easy to configure by users
- Requires Fedora specific gnome-settings-daemon and gnome-control-center patches and UI changes
- Looks like hibernation and suspend-then-hibernate is supported, while we do not support it
- Disable hibernation (and suspend-then-hibernate) in systemd
- Also removed "Hibernate" option from "Power Button action" in gnome-control-center (as we don't support it)
- Easy enough to enable for testing purposes
- Users get the more desirable suspend-then-hibernate policy by default if enabled in systemd.
- Note that I am unsure if this is currently easily possible. A systemd patch may be necessary to make this configurable.
- Hibernation disabled in Kernel
- Prevents this issue completely
- Makes it very clear we do not support hibernate
- Makes it hard to test hibernation
- Probably makes some existing users rather unhappy
- This would be a decision for the kernel team to make.
- Prefer hybrid suspend (rather than SuspendThenHibernate)
- Might result in some extra testing exposure for hibernation
- Added feature to not loose data when battery runs out
- No advantage with regard to battery runtime (suspend-then-hibernate is all about power saving)
- Is a also a bigger change in default policy in my view
- Makes suspend operation much slower
- This might be easiest to implement in systemd, not sure though i.e. disable SuspendThenHibernate and change default Suspend action
I hope that this summarises the discussion sufficiently and I didn't miss important bits.
Benjamin
On Thu, 2018-09-13 at 15:45 +0200, Hans de Goede wrote:
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
Regards,
Hans
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...
----- Original Message -----
My take on this is that we want the feature, but not as a 'try to see if it works' feature. So my suggestion is as follows:
- We disable it by default
In systemd, either in the Fedora package or upstream, and document how to enable it again for power users in the release notes.
- We develop some kind of whitelisting system to allow us to enable this on
systems we know it works (maybe tie it into the whitelisting system Hans has created for other power saving features?)
That means adding more code to the "Can*" D-Bus methods in systemd as well.
- Once we have this is place we can discuss doing a UI to allow people to
tweak behaviour of this, like they do on MacOS X, but it would be a UI that is only visible for people on whitelisted systems to tweak between known behaviours, not a 'try to turn this on to potentially break your system' UI.
Again, that behaviour is implemented in systemd itself, I'm sure they'd rather have hibernation be triggered on battery level, or at least making that timeout configurable.
Hi,
On Fri, Sep 14, 2018 at 8:53 AM, Christian Fredrik Schaller cschalle@redhat.com wrote:
My take on this is that we want the feature, but not as a 'try to see if it works' feature. So my suggestion is as follows:
- We disable it by default
- We develop some kind of whitelisting system to allow us to enable this on
systems we know it works (maybe tie it into the whitelisting system Hans has created for other power saving features?) 3) Once we have this is place we can discuss doing a UI to allow people to tweak behaviour of this, like they do on MacOS X, but it would be a UI that is only visible for people on whitelisted systems to tweak between known behaviours, not a 'try to turn this on to potentially break your system' UI.
I think this is a good idea, but the problem is, unless my information is stale, there are no systems that it works reliably on. The reason is this:
1) hibernate requires a swap partition to work 2) the swap partition needs to be at least as big as available memory 3) the swap partition can't be reserved for just hibernate to use 4) if other things end up using the swap partition then it needs to be even bigger 5) there's no limit on how much bigger it could conceivably need to be to work in all situations
so assuming i'm current and accurate on those 5 points, i don't think a whilelist is going to help until we gain a kernel feature that let's us designate a specific part of disk that's solely for hibernate to use.
--Ray
----- Original Message -----
Hi,
On Fri, Sep 14, 2018 at 8:53 AM, Christian Fredrik Schaller cschalle@redhat.com wrote:
My take on this is that we want the feature, but not as a 'try to see if it works' feature. So my suggestion is as follows:
- We disable it by default
- We develop some kind of whitelisting system to allow us to enable this
on systems we know it works (maybe tie it into the whitelisting system Hans has created for other power saving features?) 3) Once we have this is place we can discuss doing a UI to allow people to tweak behaviour of this, like they do on MacOS X, but it would be a UI that is only visible for people on whitelisted systems to tweak between known behaviours, not a 'try to turn this on to potentially break your system' UI.
I think this is a good idea, but the problem is, unless my information is stale, there are no systems that it works reliably on. The reason is this:
- hibernate requires a swap partition to work
- the swap partition needs to be at least as big as available memory
- the swap partition can't be reserved for just hibernate to use
- if other things end up using the swap partition then it needs to be
even bigger 5) there's no limit on how much bigger it could conceivably need to be to work in all situations
so assuming i'm current and accurate on those 5 points, i don't think a whilelist is going to help until we gain a kernel feature that let's us designate a specific part of disk that's solely for hibernate to use.
See the first item: https://wiki.gnome.org/BastienNocera/KernelWishlist
µswsusp is what I've been told would be the best course of action.
For systems that support it, adding native Intel Rapid Start support in the kernel would also be good, as it uses a separate partition to save the RAM: https://gist.github.com/hadess/6968197
Though Intel dropped support for the feature now, and we need this to be supported at the kernel level for systemd to add support for it...
Hi,
On 09/14/2018 02:53 PM, Christian Fredrik Schaller wrote:
My take on this is that we want the feature, but not as a 'try to see if it works' feature. So my suggestion is as follows:
- We disable it by default
- We develop some kind of whitelisting system to allow us to enable this on systems we know it works (maybe tie it into the whitelisting system Hans has created for other power saving features?)
Note I did not create a whitelist system for the powersaving features, I've done some bugfixes / implemented a safer policy then enabled those by default, together with a small blacklist for 2 of the 3 features.
Regards,
Hans
- Once we have this is place we can discuss doing a UI to allow people to tweak behaviour of this, like they do on MacOS X, but it would be a UI that is only visible for people on whitelisted systems to tweak between known behaviours, not a 'try to turn this on to potentially break your system' UI.
Christian
On Fri, Sep 14, 2018 at 7:34 AM Benjamin Berg <bberg@redhat.com mailto:bberg@redhat.com> wrote:
Hi, The issue comes up now, because systemd and gnome-settings-daemon now implement the SuspendThenHibernate option, which will automatically hibernate after 3 hours. This is a major change in policy. It is in particular problematic, as it means that we end up using hibernation by default, which is (currently) unsupported and likely to result in data loss for some users. I believe the following options were proposed: 1. Create a setting for gnome-settings-daemon to disable the SuspendThenHibernate feature and simply always use Suspend. Expose this in gnome-control-center. 2. Disable Hibernate (and SuspendThenHibernate) in systemd(-logind) 3. Disable hibernation support in the Fedora kernel 4. Disable SuspendThenHibernate and switch to hybrid suspend So, as I see it: 1. Adding a GNOME setting + Easy to configure by users - Requires Fedora specific gnome-settings-daemon and gnome-control-center patches and UI changes - Looks like hibernation and suspend-then-hibernate is supported, while we do not support it 2. Disable hibernation (and suspend-then-hibernate) in systemd + Also removed "Hibernate" option from "Power Button action" in gnome-control-center (as we don't support it) + Easy enough to enable for testing purposes + Users get the more desirable suspend-then-hibernate policy by default if enabled in systemd. * Note that I am unsure if this is currently easily possible. A systemd patch may be necessary to make this configurable. 3. Hibernation disabled in Kernel + Prevents this issue completely + Makes it very clear we do not support hibernate - Makes it hard to test hibernation - Probably makes some existing users rather unhappy * This would be a decision for the kernel team to make. 4. Prefer hybrid suspend (rather than SuspendThenHibernate) + Might result in some extra testing exposure for hibernation + Added feature to not loose data when battery runs out - No advantage with regard to battery runtime (suspend-then-hibernate is all about power saving) - Is a also a bigger change in default policy in my view - Makes suspend operation much slower * This might be easiest to implement in systemd, not sure though i.e. disable SuspendThenHibernate and change default Suspend action I hope that this summarises the discussion sufficiently and I didn't miss important bits. Benjamin On Thu, 2018-09-13 at 15:45 +0200, Hans de Goede wrote: > Hi Benjamin, Carlos, > > I'm mailing you 2 because you maintain g-s-d now. > > As discussed on the Fedora desktop mailinglist in the > > "system now hibernates automatically 3 hours after suspend ?" > > thread, the suspend-then-hibernate behavior is not really > ready for mainstream use yet (according to the systemd folks). > > Also from a kernel pov all of a sudden using hibernate is > a huge change and involves code paths which no other major > distro has been using sofar. > > So we really need to disable this for Fedora 29. And as > mentioned in the thread when we decide to enable this for > a future release, it really needs to go through the changes > process so that it is well document we are changing this > and people will have a clue what is the likely culprit > if leaving their laptop suspend for > 3h all of a sudden > breaks. > > Regards, > > Hans > > > _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org <mailto:desktop@lists.fedoraproject.org> To unsubscribe send an email to desktop-leave@lists.fedoraproject.org <mailto: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.org
On Fri, Sep 14, 2018 at 1:34 PM Benjamin Berg bberg@redhat.com wrote:
I believe the following options were proposed:
- Create a setting for gnome-settings-daemon to disable the SuspendThenHibernate feature and simply always use Suspend. Expose this in gnome-control-center.
- Disable Hibernate (and SuspendThenHibernate) in systemd(-logind)
- Disable hibernation support in the Fedora kernel
- Disable SuspendThenHibernate and switch to hybrid suspend
On my last desktop, I always suspended, because the resume is fast, the system was always plugged into electricity, and the power consumption during suspend was close to zero (measured). Hibernate or suspend-then-hibernate made no sense for me on that PC.
On my current desktop, suspend it very often broken due to some device firmware, and only hibernation works reliably. So I hibernate all the time, it's still better than a cold boot and having to restore my previous work. Hybrid sleep could be an option for me, but GNOME doesn't expose it.
As you can see, the use cases vary drastically between laptops/desktops, working/problematic hardware, and user preferences.
Whatever you choose as safe GUI options in GNOME, *please* give us the possibility to use the other ones as well. At least for power users. Whether that means additional options exposed through dconf, or whether that means an option to bypass g-s-d handling and go directly to systemd (which can be configured through logind.conf), that really doesn't matter. Just please avoid the "our way or the highway" solution. If even skilled users can't go outside of the provided super-safe boundaries, it harms our whole ecosystem. Thanks.
On Fri, 2018-09-14 at 17:16 +0200, Kamil Paral wrote:
On my current desktop, suspend it very often broken due to some device firmware, and only hibernation works reliably.
...where the hell do you *find* these systems, Kamil? You're a one in a million talent, you know that. =)
Hi!, On Thu, Sep 13, 2018 at 3:45 PM Hans de Goede hdegoede@redhat.com wrote:
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
FTR we've gone for hiding the option upstream with a compile time switch, defaulting to off. Just released gnome-settings-daemon 3.30.1.2 containing the fix.
Hopefully we'll be able to revisit the idea in the future.
Cheers, Carlos
On Thu, Oct 4, 2018, 1:34 PM Carlos Garnacho carlosg@gnome.org wrote:
Hi!, On Thu, Sep 13, 2018 at 3:45 PM Hans de Goede hdegoede@redhat.com wrote:
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is a huge change and involves code paths which no other major distro has been using sofar.
So we really need to disable this for Fedora 29. And as mentioned in the thread when we decide to enable this for a future release, it really needs to go through the changes process so that it is well document we are changing this and people will have a clue what is the likely culprit if leaving their laptop suspend for > 3h all of a sudden breaks.
FTR we've gone for hiding the option upstream with a compile time switch, defaulting to off. Just released gnome-settings-daemon 3.30.1.2 containing the fix.
Hopefully we'll be able to revisit the idea in the future.
Is the configuration exposed anywhere for users to experiment? Either tweak tool or gsettings? Changing it in systemd-logind is apparently ignored in favor of the gnome preference.
Chris Murphy
On Fri, 2018-10-05 at 08:48 -0600, Chris Murphy wrote:
On Thu, Oct 4, 2018, 1:34 PM Carlos Garnacho carlosg@gnome.org wrote:
FTR we've gone for hiding the option upstream with a compile time switch, defaulting to off. Just released gnome-settings-daemon 3.30.1.2 containing the fix.
Hopefully we'll be able to revisit the idea in the future.
Is the configuration exposed anywhere for users to experiment? Either tweak tool or gsettings? Changing it in systemd-logind is apparently ignored in favor of the gnome preference.
No, the configuration is compile time only. GNOME will only call the "Suspend" (or "Hibernate") method of systemd-logind, I believe.
The easily available change that users can do is to change the power button action (hardware button) to "hibernate" rather than suspend.
Benjamin
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Benjamin Berg -
Carlos Garnacho -
Chris Murphy -
Christian Fredrik Schaller -
Dulaney -
Frantisek Zatloukal -
Hans de Goede -
Justin Forbes -
Kamil Paral -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
mcatanzaro＠gnome.org -
Peter Robinson -
Ray Strode -
Zbigniew Jędrzejewski-Szmek