You are not logged in.
Pages: 1
I have a swap partition that I only want to use for hibernating to disk. I do not want to use it for "normal swapping".
It would be great if it was possible to hibernate to a partition without having to swapon it first but I doubt that's possible.
So I thought I would let the swap partition be off most of the time and just turn it on ahead of hibernation. I thought I could accomplish this with a systemd service like this
[Unit]
Before=systemd-hibernate.service
Before=hibernate.target
Before=sleep.target
[Service]
Type=oneshot
ExecStart=/usr/bin/swapon /dev/SWAP-PARTITION
[Install]
RequiredBy=hibernate.target
RequiredBy=sleep.target
RequiredBy=systemd-hibernate.service
But it's not working as I expected. It seems systemctl hibernate will first check if there's available swap space before starting the systemd-hibernate.service.
So I get the error message Call to Hibernate failed: Not enough swap space for hibernation before my service gets started.
Is there some other systemd target to depend on that would let me swapon before the check for available swap happens? Or can I accomplish this in some other way?
It turns out there's an environment variable SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK that you can set to 1 for systemd-logind.service that fixes it. With that set (using eg a systemd override config) the check doesn't happen and the originally described service works as expected.
Last edited by verified_abhorrer (2023-09-17 12:26:08)
Offline
Overall: https://wiki.archlinux.org/title/Power_ … leep_hooks
I do not want to use it for "normal swapping".
Jus in case: https://chrisdown.name/2018/01/02/in-de … -swap.html
Did you consider to https://wiki.archlinux.org/title/Power_ … _swap_file
You could try to edit the systemd-hibernate.service and inject an ExecStartPre, https://wiki.archlinux.org/title/System … ided_units
Did you verify that it's indeed the lack of activation that triggers this systemd behavior?
Offline
Thanks for you response, Seth.
Did you consider to https://wiki.archlinux.org/title/Power_ … _swap_file
I don't think using a swap file instead of a swap partition would change anything here. Unless I've missed something you still just hibernate into whatever you have activated as swap (be it a file or partition). The the problem of having to switch swap on and off remains.
Did you verify that it's indeed the lack of activation that triggers this systemd behavior?
I think so. If I manually run swapon before hibernating it works fine.
You could try to edit the systemd-hibernate.service and inject an ExecStartPre, https://wiki.archlinux.org/title/System … ided_units
Thank you, I will try this.
Offline
what's wrong with "vm.swappiness = 1" ?
swappiness
Offline
You could try to edit the systemd-hibernate.service and inject an ExecStartPre, https://wiki.archlinux.org/title/System … ided_units
After having tried this it seems to have the same issue as the custom service I originally described. Some check of available swap space happens before the systemd-hibernate.service service gets involved.
Offline
what's wrong with "vm.swappiness = 1" ?
swappiness
Thanks for your response! I don't know if there's anything wrong with it. Are you saying it would prevent swapping from happening? The paragraph you linked doesn't seem to imply that but I could be misunderstanding.
Offline
It does not (fully) prevent swapping, it just makes it less likey - and following the second link in #2 that is also not what you want.
wrt OT, you'd probably have to script the hibernation process (ie. you "swapon /dev/whatever && systemctl hibernate")
You could also try whether you get away w/ the hybrid sleep for this (ie. first S3, then S4 a bit later) but it might as well test the available swap before anything else.
Sounds like a systemd bug; if I eg. explicitly devise a swapfile for hibernation and it's disregarded just because it's not active at runtime, systemd acts against an explicit user will.
If there're technical limitations, one would expect it to activate the swap before this test.
Offline
It turns out there's an environment variable SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK that you can set to 1 for systemd-logind.service that fixes it. With that set (using eg a systemd override config) the check doesn't happen and the originally described service works as expected.
Last edited by verified_abhorrer (2023-09-17 12:26:35)
Offline
\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
Pages: 1