Enable sleep and after 1hour hibernate when lid is closed

,

I noticed that my t480 battery after a night of sleeping drained abot 10-30%:

I would like to enable sleep when the lid is closed, but after x time it hibernates.
I have a swap partition and enabled things in sleep.conf, but dosen’t seems like working.

Sleep]
AllowSuspend=yes
#AllowHibernation=yes
AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendMode=
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateState=disk
#HybridSleepMode=suspend platform shutdown
#HybridSleepState=disk
#HibernateDelaySec=180min
 inxi -Fazy
System:
  Kernel: 5.15.28-1-MANJARO x86_64 bits: 64 compiler: gcc v: 11.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64
    root=UUID=cc7be21e-d9d4-4881-841a-b047d2a1253a rw quiet
    udev.log_priority=3
  Desktop: i3 4.20.1 info: xfce4-panel vt: 7 dm: LightDM 1.30.0
    Distro: Manjaro Linux base: Arch Linux
Machine:
  Type: Laptop System: LENOVO product: 20L6S1LV2F v: ThinkPad T480
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: LENOVO model: 20L6S1LV2F v: SDK0J40697 WIN
    serial: <superuser required> UEFI: LENOVO v: N24ET67W (1.42 )
    date: 11/17/2021
Battery:
  ID-1: BAT0 charge: 14.8 Wh (80.0%) condition: 18.5/23.9 Wh (77.4%)
    volts: 12.1 min: 11.4 model: LGC 01AV489 type: Li-poly serial: <filter>
    status: Discharging cycles: 104
  ID-2: BAT1 charge: 10.9 Wh (84.5%) condition: 12.9/24.0 Wh (53.8%)
    volts: 12.3 min: 11.5 model: SMP 01AV452 type: Li-poly serial: <filter>
    status: Not charging cycles: 209
CPU:
  Info: model: Intel Core i5-8350U bits: 64 type: MT MCP arch: Coffee Lake
    family: 6 model-id: 0x8E (142) stepping: 0xA (10) microcode: 0xEC
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB
    L3: 6 MiB desc: 1x6 MiB
  Speed (MHz): avg: 799 high: 801 min/max: 400/3600 scaling:
    driver: intel_pstate governor: powersave cores: 1: 800 2: 800 3: 801 4: 800
    5: 800 6: 798 7: 800 8: 800 bogomips: 30409
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf
    mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
    STIBP: conditional, RSB filling
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort mitigation: TSX disabled
Graphics:
  Device-1: Intel UHD Graphics 620 vendor: Lenovo driver: i915 v: kernel
    ports: active: eDP-1 empty: DP-1, DP-2, HDMI-A-1, HDMI-A-2 bus-ID: 00:02.0
    chip-ID: 8086:5917 class-ID: 0300
  Device-2: Chicony Integrated Camera (1280x720@30) type: USB
    driver: uvcvideo bus-ID: 1-8:4 chip-ID: 04f2:b604 class-ID: 0e02
    serial: <filter>
  Display: x11 server: X.Org v: 1.21.1.3 compositor: Picom v: git-7e568
    driver: X: loaded: modesetting alternate: fbdev,vesa gpu: i915
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x286mm (20.0x11.3")
    s-diag: 583mm (23")
  Monitor-1: eDP-1 model: LG built: 2016 res: 1920x1080 dpi: 158 gamma: 1.2
    size: 309x174mm (12.2x6.9") diag: 355mm (14") ratio: 16:9 modes: 1920x1080
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2) v: 4.6 Mesa 21.3.7
    direct render: Yes
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: Lenovo ThinkPad T480
    driver: snd_hda_intel v: kernel alternate: snd_soc_skl bus-ID: 00:1f.3
    chip-ID: 8086:9d71 class-ID: 0403
  Sound Server-1: ALSA v: k5.15.28-1-MANJARO running: yes
  Sound Server-2: JACK v: 1.9.20 running: no
  Sound Server-3: PulseAudio v: 15.0 running: yes
  Sound Server-4: PipeWire v: 0.3.48 running: no
Network:
  Device-1: Intel Wireless 8265 / 8275 driver: iwlwifi v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 bus-ID: 03:00.0 chip-ID: 8086:24fd class-ID: 0280
  IF: wlp3s0 state: up mac: <filter>
Bluetooth:
  Device-1: Intel Bluetooth wireless interface type: USB driver: btusb v: 0.8
    bus-ID: 1-7:3 chip-ID: 8087:0a2b class-ID: e001
  Report: rfkill ID: hci0 rfk-id: 1 state: down bt-service: disabled
    rfk-block: hardware: no software: no address: see --recommends
Drives:
  Local Storage: total: 238.47 GiB used: 71.69 GiB (30.1%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Intel model: SSDPEKKF256G8L
    size: 238.47 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
    lanes: 4 type: SSD serial: <filter> rev: L15P temp: 30.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 118.93 GiB size: 116.5 GiB (97.96%)
    used: 71.67 GiB (61.5%) fs: ext4 dev: /dev/nvme0n1p5 maj-min: 259:5
  ID-2: /boot/efi raw-size: 100 MiB size: 96 MiB (96.00%)
    used: 25.3 MiB (26.3%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
Swap:
  Kernel: swappiness: 60 (default) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 8 GiB used: 0 KiB (0.0%) priority: -2
    file: /swapfile
Sensors:
  System Temperatures: cpu: 37.0 C pch: 34.0 C mobo: N/A
  Fan Speeds (RPM): fan-1: 0
Info:
  Processes: 219 Uptime: 2h 49m wakeups: 12 Memory: 7.51 GiB
  used: 2.28 GiB (30.3%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 11.2.0 clang: 13.0.1 Packages: pacman: 1283 lib: 367 Shell: Bash
  v: 5.1.16 running-in: xfce4-terminal inxi: 3.3.13

This is already the default setting - uncommenting it does nothing.

I think you have a conceptual problem.
If the system is suspended - it is suspended.
You’ll have to wake it up to have it then again enter a different state, hibernate this time.
It’s hard to automate this when the machine isn’t running. :wink:

Then there is hybrid sleep - it first hibernates, to write the data to disk, then it comes back and suspends.
If the battery runs out and the RAM content is lost, the system will wake up from disk instead.

1 Like

I see.
So this is some thing i cant really adjust.
Well, i think i have to live with it.

I have no problems with this on my machine, but is seems yours behaves a bit … differently, is problematic in this regard.

So I read a little and found this site:

Fine tuning of power management with suspend ("standby") - TUXEDO Computers

and this:

https://www.kernel.org/doc/Documentation/power/states.txt

For me, the output of:
cat /sys/power/mem_sleep
is:
s2idle [deep]

I do not know whether that is different for you or could easily be adapted.

The information in the second link seems to suggest something.

The default suspend mode (ie. the one to be used without writing anything into
/sys/power/mem_sleep) is either “deep” (if Suspend-To-RAM is supported) or
“s2idle”, but it can be overridden by the value of the “mem_sleep_default”
parameter in the kernel command line.

But I do not know nor can I judge the possible significance of this for you.
Perhaps it is some helpful info though.

I have never tested how long my laptop will be able to be in suspend mode before the battery runs out - if I anticipate that it will be a long time, I use hybrid sleep - then it does not matter whether the battery runs out.

1 Like

not what the wiki says:

There are also two modes combining suspend and hibernate:

  • systemctl hybrid-sleep suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called suspend to both.
  • systemctl suspend-then-hibernate initially suspends the system to RAM and if it is not interrupted within the delay specified by HibernateDelaySec in systemd-sleep.conf(5), then the system will be woken using an RTC alarm and hibernated.

This is default on my Manjaro 21.2.5 (Gnome) system, after properly configuring swap to file for BTRFS and enabling hibernation:

sleep.conf

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendMode=
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateState=disk
#HybridSleepMode=suspend platform shutdown
#HybridSleepState=disk
HibernateDelaySec=60min

However it also does not do what I want (not sure if it ever did, I do believe something changed after an update):

  1. I want hybrid sleep, always. If you have a fast SSD, there is really no reason not to do this. Always write to both SSD and RAM.
  2. I want SuspendThenHibernate after 60min suspend.
  3. I want this regardless whether I am on battery or not (because I could unplug the system after it has suspended.

The Arch Wiki is in my opinion the best documentation, far better than any other distribution like Ubuntu. But when it comes to sleep, it lets me down a little I have read these article and this article in the wiki, but no where is stated what values to use:

https://wiki.archlinux.org/title/Power_management#Suspend_and_hibernate
https://man.archlinux.org/man/systemd-sleep.conf.5

I can’t figure out how to get both hybrid sleep (always, regardless of battery power or not) and SuspendThenHibernate (always, regardless of battery or not)?

1 Like

I see no contradiction there.

I think you have a conceptual problem, too. :wink:

These are two functionally exclusive things.

One intentionally keeps the RAM alive and only resumes from disk once the power to RAM is cut/battery is drained/RAM content is lost

the goal of the other is to eventually suspend to disk
and then to power down everything, including the RAM

The second option always resumes from disk - the RAM is not kept alive and the battery isn’t drained till empty.

The two options quite literally do the procedure the other way around
and have a different goal/end result.
Can’t have both ways at the same time.

Sorry but you are 100% incorrect, not according to me, but to the definition in the Arch wiki, it clearly states the definition of hybrid-sleep:

suspends the system both to RAM and disk

That is exactly not what you are writing, as you clearly mention 2 actions for Hybrid sleep, first suspend, then it comes back and does hibernate. That is not Hybrid Sleep. Not according to the wiki.

No, they litterally do not. Hybrid sleep, when initiated, immediately writes to BOTH and then it is done performing any actions. It does not wake up to write to disk.

No, because after Hybrid Sleep, the system stays suspended (and keeps consuming power). There is no other action after HibernateDelaySec is reached, because this value is for suspend-then-hibernate, it has nothing to do with Hybrid Sleep. If you want your system to wake up from suspend to go into hibernate (no power consumption), it does not matter whether data has been written only to RAM or (because of Hybrid Sleep instead of Suspend) to both RAM and swap already.

They do not exclude each other.

It is perfectly fine to decide you want it to hibernate after 60 minutes of suspend. Since that is exactly what Suspend-Then-Hibernate is for. Why suddenly this functionality is blocked simply because the required data is already in swap makes no sense. It could only benefit from that.

I recommend you read the Arch wiki a couple of times.

Then you will also understand suspend-then-hibernate means there are plenty of cases where hibernate is not triggered. That is why the combination with Hybrid Sleep (which is simply Suspend but with ram also written to swap at the same time) is very handy.

I will not argue who is right or wrong.
You already decided that for you - and so did I. :wink:

Good luck in your endeavours!

Seriously, just read that first quote… You are mixing up definitions, which is actually very understandable, because the definitions are easy to mix up :slight_smile: Hybrid Sleep is not what wakes up your system… that is what suspend-then-hibernate does.

Find 1 person who has read the Arch Wiki and agrees with you please…

@Nachlese here you go:


That is a screenshot from the Arch Wiki link that I shared with you earlier…

… this is funny :wink:
you say things that I never said - and then try to correct me on it

Have you actually tried and observed one method, then the other?
It may be hard with an SSD as it is already so fast.
With a spinning disk you’ll see clearly what happens.
hybrid-sleep will write to disk, then suspend to RAM
and will wake up from RAM if it was preserved (the power was not interrupted)
and it will wake up from disk if power was not preserved.

suspend-then-hibernate will wait some time (in suspend to RAM state)
then wake up and suspend to disk
Wake up is from disk after that point - RAM is not preserved anymore.
The battery isn’t drained/power isn’t needed anymore.

I wonder why you can’t get to work what you so well understand.

This will have been my last reply.

Best of luck to you!

I really do not mind discussing, but actually blaming someone of lying is pretty bad behaviour.

Your 1st post:

That is the part I am trying to help you understand, is closer to the definition of suspend-then-hibernate, not hybrid-sleep. Or you could just read the wiki… because it is not even the definition of suspend-then-hibernate.

What you are describing is litterally hibernate-then-suspend, which does not really exist :slight_smile: But I do understand the effort you made here.

Be very careful with calling people liars when all that happened was reminding you of misrepresentation.

You lied when you said I say things you never said… then I show you a screenshot of what you said, marked it for you and reminded you, You did say what I said you said.

But it seems you refuse to accept the Arch Wiki, or even just read my full posts… with clear screenshots. This almost Reddit material :slight_smile: so I don’t mind spending more time.

Have you had time to look at the screenshots?
Would you mind just stating what you now believe is the definition of Hybrid Sleep in the context of the OS we are talking about here?

Back on topic, following the documentation exactly, this is now part of my post-install script. I use Gnome, but this is not dependent on Gnome:

# GOAL: system should not use Suspend anymore. Always use Hybrid Sleep and Suspend-Then-Hibernate. Use Hibernate when power key is hit. Use Suspend-Then-Hibernate when lid is closed.  
#
# follow https://wiki.archlinux.org/title/Power_management#Hybrid-sleep_on_suspend_or_hibernation_request
# follow https://man.archlinux.org/man/sleep.conf.d.5
# 
# Disable regular suspend, we only allow Hybrid Sleep, to prevent data loss when battery dies
sed -i -e 's@#AllowSuspend=yes@AllowSuspend=no@g' /etc/systemd/sleep.conf
# Disabling suspend implies disabling suspend-then-hibernate and hybrid-sleep, override to allow both again
sed -i -e 's@#AllowHybridSleep=yes@AllowHybridSleep=yes@g' /etc/systemd/sleep.conf
sed -i -e 's@#AllowSuspendThenHibernate=yes@AllowSuspendThenHibernate=yes@g' /etc/systemd/sleep.conf
# Define the method of suspend to be Hybrid Sleep, this is also used by suspend-then-hibernate to determine how to suspend.
sed -i -e 's@#SuspendMode=@SuspendMode=suspend@g' /etc/systemd/sleep.conf
sed -i -e 's@#SuspendState=mem standby freeze@SuspendState=disk@g' /etc/systemd/sleep.conf
# when suspend-then-hibernate is used, go into hibernation (0.0 power consumption) after 60min of suspend unless interrupted
sed -i -e 's@#HibernateDelaySec=180min@HibernateDelaySec=60min@g' /etc/systemd/sleep.conf

# Now define what to do on user initiated actions: go into hibernation when hitting power key
sed -i -e 's@#HandlePowerKey=poweroff@HandlePowerKey=hibernate@g' /etc/systemd/logind.conf
# Use suspend-then-hibernate when lid is closed, even when on external power since you could disconnect from power during suspend
sed -i -e 's@HandleLidSwitch=ignore@HandleLidSwitch=suspend-then-hibernate@g' /etc/systemd/logind.conf
sed -i -e 's@#HandleLidSwitchExternalPower=suspend@HandleLidSwitchExternalPower=suspend-then-hibernate@g' /etc/systemd/logind.conf

this is just changing values according to the Wiki. Will test all of it.

Hi @zilexa,

Thanks for sharing all this info.
What is your feedback since then?

@xakraz hibernation wasn’t working, the wiki to enable this on BTRFS filesystem is updated and now it works again. I have updated my script. More info here:

The Arch wiki articles on how to enable suspend-then-hibernate are incorrect, this suspend-then-hibernate isn’t even a supported value in sleep.conf and logind.conf, contrary to what the wiki says. The only way to get it working is by symlinking it to the suspend service. See my script.

You can still also enable hybrid sleep by changing the State in sleep.conf to disk, but it is less useful with the way suspend-then-hibernate now works.