Talk:Power management/Suspend and hibernate

From ArchWiki

Modifying the hibernation mode

Hi, I've experienced a couple of problems with the default "platform" kernel hibernation mode on my laptop (basically, sometimes the hibernation image fails to resume, leading to a reboot), so I've been testing the steps shown here [1]. In fact, changing to "shutdown" mode does work. There is a way to force systemd to use a specific mode/state configuration by means of creating /etc/systemd/sleep.conf according to man systemd-sleep.conf. I'd add this to the wiki, but I'm not sure which is the most appropriate section to add this information, whether Power management#systemd or Power management#Troubleshooting. --Eugenio M. Vigo (talk) 16:41, 28 March 2016 (UTC)

I think you can put it under Power_management#Power_management_with_systemd, since sleep.conf isn't mentioned at all in the article yet, and the new section could be expanded and generalized. In any case we're always in time to move it somewhere else if needed. — Kynikos (talk) 07:07, 30 March 2016 (UTC)

Suspend on LynxPoint

I had to disable SLPB and JMC2 too, to avoid instantaneous wakeups from suspend. Should we add this to the list of acpi devices in the "Suspend on LynxPoint" section? Dervomsee (talk) 11:54, 5 March 2017 (UTC)

Is the introduction too long?

The introduction is much longer than other pages, should we move it to its own section such as "suspending methods"? --Fengchao (talk) 06:39, 15 November 2017 (UTC)

Admittedly the introduction is quite lengthy but nevertheless descriptive and it provides the necessary information to understand the following chapters. IMHO I would keep it as it is. -- Edh (talk) 19:13, 15 November 2017 (UTC)
I agree, the problem with separate "introduction" sections is that they would still need to be introduced at the top of the page. -- Lahwaacz (talk) 19:25, 15 November 2017 (UTC)
It is just a style change, no change to actual content. Currently the whole introduction is above the table of contents. When table of contents is expanded, looks bad from my point of view. Add a section will keep table of contents at the top of page. --Fengchao (talk) 03:31, 16 November 2017 (UTC)
Right, I already assumed, that you were just intending to move stuff around without changing the content. Nevertheless I still think that the current introduction is the way to go since it is essential for understanding the following content. However feel free to disregard my opinion. I do not feel to strongly about it. -- Edh (talk) 20:59, 16 November 2017 (UTC)

Suspend then hibernate

To be honest, I find this article somewhat underwhelming when it comes to dealing with modern suspend/hibernation methods.

1. I have personally set up my system to use Intel Rapid Start Technology (IRST), which works great for my purposes, on my machine. Unfortunately it seems that there is virtually no information on IRST on the Arch Wiki.

2. Other than IRST, this page does not make any mention of configuring suspend-then-hibernate (briefly mentioned here).

Both suspend-then-hibernate methods are better than "suspend to both", IMO, since there will be a much shorter delay before going to sleep, and the system will always hibernate after the timeout is reached, rather than when the battery is nearly depleted. This means that you can close your laptop lid, and leave it for a few days yet always be certain that you have a fairly decent amount of battery power left once you resume your system.

Is there a reason this wiki article does not include information on either method, or would it be appreciated if I put time into adding instructions on how to enable them?

Or, in the case of IRST, we should perhaps create a separate page for it? It can then include a list of laptops verified to work with it, since it seems to depend on firmware/BIOS support.

--Abtz (talk) 15:59, 6 October 2018 (UTC)

Just because some information is not there does not mean that it is missing. systemctl suspend-then-hibernate should work out of the box assuming that suspend as well as hibernate, both of which are fairly well documented, actually work. The action that should happen when you close the lid can be configured as described in Power management#ACPI events which also includes suspend-then-hibernate. -- Lahwaacz (talk) 09:39, 17 February 2019 (UTC)
Note that IRST does not encrypt the contents of the RAM before saving them to disk. The recommended way to achieve disk encryption with IRST is to use ATA disk encryption which is not considered as secure as software based solutions. Lucaspiller (talk) 08:38, 11 March 2019 (UTC)
On suspend-then-hibernate, I've found in this forum that the only effective way to set it up is using a symlink... # ln -s /usr/lib/systemd/system/systemd-suspend-then-hibernate.service /etc/systemd/system/systemd-suspend.service. I've tried the following in /etc/systemd/sleep.conf with no success:

Either with SuspendState=suspend-then-hibernate suspension is not enabled. Being curious I tried SuspendState=mem standby freeze suspend-then-hibernate, but it only leads to suspension in memory and never trying hibernation.

Although the man page man systemd-sleep.conf mentions

              SuspendMode=, HibernateMode=, HybridSleepMode=
              The string to be written to /sys/power/disk by, respectively, systemd-
              suspend.service(8), systemd-hibernate.service(8), systemd-hybrid-
              sleep.service(8), or systemd-suspend-then-hibernate.service(8). More
              than one value can be specified by separating multiple values with
              whitespace. They will be tried in turn, until one is written without
              error. If neither succeeds, the operation will be aborted.
              SuspendState=, HibernateState=, HybridSleepState=
              The string to be written to /sys/power/state by, respectively, systemd-
              suspend.service(8), systemd-hibernate.service(8), systemd-hybrid-
              sleep.service(8), or systemd-suspend-then-hibernate.service(8). More
              than one value can be specified by separating multiple values with
              whitespace. They will be tried in turn, until one is written without
              error. If neither succeeds, the operation will be aborted.

it seems that suspend-then-hibernate is not a valid value neither for /sys/power/disk nor /sys/power/state. Nicoadamo (talk) 16:09, 10 November 2019 (UTC)

Does systemctl suspend-then-hibernate not work for you? Systemd supports the actions suspend, hibernate, hybrid-sleep and suspend-then-hibernate, but it does not support one action to replace another. Hence, suspend will always suspend and not suspend-then-hibernate. If you want to suspend-then-hibernate, you need to suspend-then-hibernate. Or if you use some kind of GUI or power manager which supports only suspend, you need to extend it to support suspend-then-hibernate. Or stop using it and use systemd directly. -- Lahwaacz (talk) 17:19, 10 November 2019 (UTC)
You're totally right, I've found that out too late. Either suspend is called, or suspend-then-hibernate is called. suspend is not supposed to call later the hibernation itself. KDE/Plasma/PowerDevil has not yet implemented the corresponding call to suspend-then-hibernate. The aforementioned forum mentions that KDE should show a new option for Suspend then hibernate for PowerDevil 5.17, but as of 9-Nov-19 and v5.17.2, it is still not available. Nicoadamo (talk) 18:52, 10 November 2019 (UTC)
On a new install (February 2020), I'm having trouble setting up suspend-then-hibernate following the instructions here. sudo systemctl suspend-then-hibernate works unproblematically, after setting up hibernate as described in that section. But if I add the line SuspendMode=suspend-then-hibernate or try setting the Gnome suspend function to suspend-then-hibernate with gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type suspend-then-hibernate I get an error along the lines of Failed to suspend system via logind: Sleep verb "suspend" not supported. I suspect that the documentation is incorrect somewhere but am not sure what to do about it. All packages are up to date as of Feb 24, 2020. titaniumbones
SuspendMode=suspend-then-hibernate is not supported, please read my previous reply in this section for explanation. The GNOME way has the same problem. -- Lahwaacz (talk) 21:58, 24 February 2020 (UTC)
ah, I was misunderstanding your previous post. Does this mean that I should be able to use HandleLidSwitch=suspend-then-hibernate, HibernateDelaySec=1800 in /etc/systemd/logind.conf, instead? That also is not currently working for me, though maybe it is being overridden by Gnome. I'm a little uncertain what level I need to be working at to address this issue. —This unsigned comment is by Titaniumbones (talk) 22:32, 24 February 2020‎. Please sign your posts with ~~~~!
logind.conf(5) shows all possible configuration keys and values. I don't use GNOME so I have no idea what it does. -- Lahwaacz (talk) 07:30, 25 February 2020 (UTC)

Suspend/hibernate does not work, or does not work consistently

The article is right: using linux-lts and an empty MODULES=() in /etc/mkinitcpio.conf, awaking from hibernation is successful. But if using radeon drivers for video and SDDM, MODULES=(radeon) in /etc/mkinitcpio.conf is mandatory for the initial boot since some update back in September, 2019. Consequently, this results in a loop... Was anyone successful to set hibernation with radeon and SDDM? Nicoadamo (talk) 16:09, 10 November 2019 (UTC)

I confirm that using AMDGPU hibernation works fine on a quite old AMD A10 7300 (Radeon R7 M265 codenamed Sea Islands). Nicoadamo (talk) 12:57, 17 November 2019 (UTC)

systemd-tmpfiles for setting image_size permanently

In section "About swap partition/file size", it says "See systemd#systemd-tmpfiles - temporary files to make this change persistent." However, the article about systemd-tmpfiles linked warns "Note: This method may not work to set options in /sys since the systemd-tmpfiles-setup service may run before the appropriate device modules are loaded." If it is the case that systemd-tmpfiles will always work for writing to the /sys/power/image_size file, it would be nice if the aforementioned section clearly says so and thus eases any potential worry. If it is the case that systemd-tmpfiles won't always work for writing to the /sys/power/image_size file, it would be nice if the aforementioned section recommends a different way to make the change permanent or at least clearly says that the systemd-tmpfiles method may only work sometimes. Does anyone know if systemd-tmpfiles will always set the value of /sys/power/image_size correctly? Ricardo (talk) 04:47, 8 February 2022 (UTC)