Suspend but No Hibernate with Systemd

Kale Good · 2019-01-18 04:20:56

I have two swap files; one on an SSD (2G swapfile, /dev/sdc2), another on an HD (10G hd-swapfile, /dev/sda3).
I can suspend but not hibernate. I get a "sleep verb hibernate not supported". A fedora forum suggests, well, all the stuff I thought I did already.

I've tried to give every relevant file here. Not sure what I'm missing.

Related but not exactly the same question: 1) My Idle Timer in logind doesn't seem to be working. I'm assuming that just means "after X mins of no user input, do action X" 2) Is there a way to turn off the idle/auto-suspend without running systemctl restart systemd-logind

blkid

/dev/sda1: LABEL="Arch Live CD" UUID="c5c096b9-b4ad-44ec-8d81-ab550af85def" TYPE="ext4" PARTLABEL="Arch Live CD" PARTUUID="9f3b1538-623c-4a74-a6df-ffc664ff02f7"
/dev/sda2: LABEL="MiscUse" UUID="0f8d3756-63dc-4602-b1cb-cdf61ea104f2" TYPE="ext4" PARTLABEL="MiscUse" PARTUUID="687d7c77-880b-40c1-bd20-121aabbf79fa"
/dev/sda3: LABEL="backups" UUID="7eb38b44-6dc5-4c1e-b5fc-732201320555" TYPE="ext4" PARTLABEL="backups" PARTUUID="fec75876-3f3a-426a-9314-d255eb84a760"
/dev/sdb1: UUID="719b1945-c32e-4f25-ba5e-558f2154e148" TYPE="ext4" PARTUUID="087cda9b-01"
/dev/sdc1: UUID="014C-903F" TYPE="vfat" PARTUUID="5b5becc1-44ea-6f48-bcfa-689093d3abcc"
/dev/sdc2: UUID="43a01aea-191c-476e-940e-830749c81e9b" TYPE="ext4" PARTUUID="3815daa3-1e12-9441-ad95-6f367a49033c"

/etc/fstab

# /dev/sdd2
UUID=43a01aea-191c-476e-940e-830749c81e9b	/         	ext4      	rw,relatime	0 1

# /dev/sdd1
UUID=014C-903F      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro	0 2

#my addition, home folder on 2TB drive
UUID=719b1945-c32e-4f25-ba5e-558f2154e148 /mnt/home.2tb/		ext4			rw,relatime 0 2 

#my addition, backups on 4TB drive. 
UUID=7eb38b44-6dc5-4c1e-b5fc-732201320555 /mnt/backups/ ext4 			ro,relatime 0 2

#added small swap general use. SSD
/swapfile none swap defaults,pri=100 0 0

#added big swap for hibernation. HDD
/mnt/home.2tb/hd-swapfile none swap defaults,pri=0 0 0

/etc/defaults/grub (grub-mkconfig has been run)

# GRUB boot loader configuration

GRUB_DEFAULT=0
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=43a01aea-191c-476e-940e-830749c81e9b resume_offset=7015962"
GRUB_CMDLINE_LINUX=""

filefrag -v /swapfile

ext:     logical_offset:        physical_offset: length:   expected: flags:
  0:        0..       0:    7015962..   7015962:      1:            
  1:        1..   22527:    1058048..   1080574:  22527:    7015963: unwritten

/etc/systemd/logind/conf

HandlePowerKey=suspend
IdleAction=suspend
IdleActionSec=5min

/etc/systemd/sleep.conf

[Sleep]
# suspend
SuspendMode=hibernate
SuspendState=disk
#HibernateDelaySec=3600

# hibernate
HibernateMode=hibernate
HibernateDelaySec=900
HibernateState=mem

/etc/mkinitcpio.conf

HOOKS=(base udev autodetect modconf block filesystems keyboard resume fsck)

V1del · 2019-01-18 08:54:21

That sleep.conf doesn't make sense, you want mem as the SuspendState and disk as HibernateState. The SuspendMode values also don't make much sense From

man systemd-sleep.conf wrote:

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.

And valid values are

Kernel docs wrote:

/sys/power/disk controls the operating mode of hibernation (Suspend-to-Disk).
Specifically, it tells the kernel what to do after creating a hibernation image.
Reading from it returns a list of supported options encoded as:
'platform' (put the system into sleep using a platform-provided method)
'shutdown' (shut the system down)
'reboot' (reboot the system)
'suspend' (trigger a Suspend-to-RAM transition)
'test_resume' (resume-after-hibernation test mode)

Kale Good · 2019-01-18 13:47:45

Ok, I changed it so it doesn't throw errors, but I'm still confused and unsure of what my system is doing.

[Sleep]
#suspend
#I assume this just suspends to ram. that seems pretty clear. 
SuspendMode=suspend
SuspendState=mem
#HibernateDelaySec=3600


#hibernate
# suspend and write to disk instead of memory. Simple enough; we just call it hibernate.
# However, this is actually the example for a hybrid sleep from the wiki. 
# Which I really don't understand. Where do things get written to mem? By the suspend call?
# If so, how do we have a pure disk-hibernation state?
# Also, would enabling suspend-then-hibernate simply require uncommenting #HibernateDelaySec?
HibernateMode=suspend
HibernateState=disk
#HibernateDelaySec=900

V1del · 2019-01-18 14:20:21

Pure disk hibernation is with HibernateMode=shutdown . Yes suspend-then-hibernate would look at the HibernateDelaySec for when to initialize the hibernation.

FWIW I'm pretty sure that that file should already come with sane defaults to do just what you expect (except maybe uncomment and set a HibernateDelaySec) why are you adjusting it that much in the first place?

Also in general since you didn't mention anything otherwise, you do use logind/systemd for these? As in the session you are running doesn't have it's own power management settings that might clash here?

Kale Good · 2019-01-18 14:39:37

V1del wrote:

FWIW I'm pretty sure that that file should already come with sane defaults to do just what you expect...why are you adjusting it that much in the first place?

I had no /etc/systemd/sleep.conf, so I just copied and pasted the one file I found on the wiki and have been trying to figure it out through trial and error.

I'm running gnome and have power management settings set to "off" via the system settings power management menu. I assume that's all I have to do to avoid conflict.

how's this look?

[Sleep]
#suspend
SuspendMode=suspend
SuspendState=mem
#HibernateDelaySec=3600

#hibernate: suspend-then-hibernate
HibernateMode=shutdown
HibernateDelaySec=900
HibernateState=disk

V1del · 2019-01-18 15:14:04

Ah you're right, weird, usually a default file is placed there with all default entries commented.

But yes that should be fine. Not entirely sure how the kernel handles on where exactly to put the hibernation image in a case such as yours but I guess you'll have to test.

Kale Good · 2019-01-18 16:50:35

Still some problems, and I'm sure how to troubleshoot.

1) I've got hibernation working with:

#suspend
SuspendMode=suspend
SuspendState=mem

#hibernate: suspend-then-hibernate
HibernateMode=shutdown
HibernateDelaySec=900
HibernateState=disk

However, systemctl hibernate seems to go straight to disk-written hibernate (keyboard input won't wake, power key press brings up grub menu, power light goes off). This is quite different than suspend, which keeps the power light blinking.

So it looks like I need something more for suspend-then-hibernate to work.

2) I can't get IDLETIME working in logind.conf. Docs say "The system will execute the action after all sessions report that they are idle, no idle inhibitor lock is active, and subsequently, the time configured with IdleActionSec= (see below) has expired.", but I don't have a clue where to look for idle reports or idle inhibitors.

V1del · 2019-01-18 17:12:16

Yes that's what's supposed to happen, if you want suspend-then-hibernate then use literally

systemctl suspend-then-hibernate

and make your IdleAction=suspend-then-hibernate

As for inhibition information

systemd-inhibit --list

should show currently active inhibitors. And to check if you have a valid session

loginctl session-status

I'd hazard a guess that if you use Gnome and disable it's own power management that might disable these idle events as well. FWIW Is there a particular reason you are manually doing this, while - at least to my knowledge - the gnome management utilities should allow you to configure this and be more or less guaranteed to work?

And if the Idle action did actually take place and was blocked for some reason, your journal will contain information on that

sudo journalctl -b #For the current boot

.

Last edited by V1del (2019-01-18 17:17:26)

Kale Good · 2019-01-18 23:12:45

Ah, ok, got it. I thought sleep.conf set defaults for the systemctl hibernate & suspend commands.

Manually (vs. Gnome) because I've been having issue in Gnome and been bouncing around different DEs and I want my settings consistent. Also, Gnome only has Suspend after inactivity; there is no hibernate after inactivity (much less suspend-then-hibernate).

Plus, a bit of a learning experience.

Last edited by Kale Good (2019-01-19 04:34:09)

Kale Good · 2019-01-20 17:15:21

Ok, new issue here. I've got hibernate working, but I occasionally get

Failed to hibernate system via logind: Not enough swap space for hibernation

despite the fact that free swap space > RAM.

V1del · 2019-01-20 22:06:27

You are using the wrong UUID (and for that matter likely wrong offset of course) in your resume= line, point that to the bigger HDD, the uuid mentioned there will also be the one where the hibernation image will be written to

Last edited by V1del (2019-01-20 22:42:12)

Kale Good · 2019-01-21 00:26:30

Ah, got it. I had tried that earlier, but was having issues I assumed was due to it's lower priority (but were actually due to my sleep.conf file).

Kale Good · 2019-01-21 19:11:38

I switched the setup to the hd swapfile. Now I either a) am allowed to hibernate by systemd; however, when I resume, I do not resume to the same session (it looks like a shutdown and power-up cycle for all I can tell.) 2) I get exactly the same error as before; not enough space, even when htop shows nothing written to swap.

from /etc/fstab

#my addition, home folder on 2TB drive
UUID=719b1945-c32e-4f25-ba5e-558f2154e148 /mnt/home.2tb/		ext4			rw,relatime 0 2 

#added big swap for hybernation. HDD
/mnt/home.2tb/hd-swapfile none swap defaults,pri=0 0 0

from filefrag -v /mnt/home.2tb/hd-swapfile

ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:  376315904.. 376315904:      1:

from /etc/defaults/grub

#hd-swapfile for hibernate
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=719b1945-c32e-4f25-ba5e-558f2154e148 resume_offset=376315904"

Kale Good · 2019-01-23 14:40:19

Ok, I'm trying to figure out if this is a priority issue. What is the expected behavior when the Resume swapfile (or partition) is a lower-priority?

(for example, in my setup, I'd like to have a small SSD swap space and a larger swapspace for hibernation on my HD). (I am using swap files)

I tried testing this out earlier today and it appeared that priority was key; however, I need to do more testing (see test cycle below).

My working-assumption is that the kernel "resume=" command indicates where the kernel should look for resume data. However, there is no way to specify which swap space resume data is written to. Ergo, the system writes to the higher-priority swap space (SSD, in my case), while the kernel looks to the lower priority swap space (HD) and fails. Without finding any resume data, it simply reboots.

More testing needed: After several successful resumes that tested HD vs. SSD swap file and priority, I thought I understood what was happening. Here was my cycle:

I tested resuming from SSD as swap. Resume successful.

HD as swap, SSD disabled. Reboot after grub-mkconfig required, as parameters changed. worked.

Without rebooting, HD as swap, top priority, set via swapon -p. I did not reboot before testing swap. It worked.

I might've tested HD as top priority, set via /etc/fstab. If I did this, it worked, because I went to the next step. (I may have assumed that /etc/fstab was reloaded during a resume-from-suspend and not rebooted before testing this).

Without rebooting (from most recent successful resume). I then tested HD swap as lower priority, set via swapon. Again, it worked. This was a surprise, as I had assumed it was a priority issue.

Without rebooting, I set HD as lower priority via /etc/fstab. I thought that maybe /etc/fstab was reloaded during a resume cycle, so I tried a resume (without reboot) here. It worked. Again, I was surprised. This is where I realized that /etc/fstab is likely not reloaded during resume-from-suspend.

So I rebooted to ensure that /etc/fstab was reloaded. And now hibernate fails.

And that's all the time I've had to fiddle with it. Barring any guidance, my next setup is going to be the same test cycle with a full-reboot before every resume test.

Last edited by Kale Good (2019-01-23 14:41:49)

Kale Good · 2019-01-24 13:24:40

I tried a hd partition instead of an hd file, on the thought that the issue might've been file fragmentation. No luck.

Arch Linux

#1 2019-01-18 04:20:56

Suspend but No Hibernate with Systemd

#2 2019-01-18 08:54:21

Re: Suspend but No Hibernate with Systemd

#3 2019-01-18 13:47:45

Re: Suspend but No Hibernate with Systemd

#4 2019-01-18 14:20:21

Re: Suspend but No Hibernate with Systemd

#5 2019-01-18 14:39:37

Re: Suspend but No Hibernate with Systemd

#6 2019-01-18 15:14:04

Re: Suspend but No Hibernate with Systemd

#7 2019-01-18 16:50:35

Re: Suspend but No Hibernate with Systemd

#8 2019-01-18 17:12:16

Re: Suspend but No Hibernate with Systemd

#9 2019-01-18 23:12:45

Re: Suspend but No Hibernate with Systemd

#10 2019-01-20 17:15:21

Re: Suspend but No Hibernate with Systemd

#11 2019-01-20 22:06:27

Re: Suspend but No Hibernate with Systemd

#12 2019-01-21 00:26:30

Re: Suspend but No Hibernate with Systemd

#13 2019-01-21 19:11:38

Re: Suspend but No Hibernate with Systemd

#14 2019-01-23 14:40:19

Re: Suspend but No Hibernate with Systemd

#15 2019-01-24 13:24:40

Re: Suspend but No Hibernate with Systemd

Board footer