Hibernate fails - cannot allocate memory

Support
,
1

Sometimes when hibernating, the screen goes blank for about half a minute, then returns to the login screen. Session is still running. I can login to resume session and usually I can go straight to hibernate and it works the second time.
Most of the times when hibernate has failed there is a VM running, or has been a VM shutdown within the past 15ish minutes, prior to the hibernate fails. I’m using Virtualbox for VM’s.

When it fails due to low battery, it is causing problems as it doesn’t automatically tries a second time and runs out of battery before I realize it needs my attention.

When it fails, the log looks like this:

# journalctl --boot 0 --since "2025-06-18 15:00" |grep sleep
juni 18 22:07:10 pl2 NetworkManager[853]: <info>  [1750277230.8832] manager: sleep: sleep requested (sleeping: no  enabled: yes)
juni 18 22:07:10 pl2 NetworkManager[853]: <info>  [1750277230.8836] device (p2p-dev-wlp2s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping', managed-type: 'full')
juni 18 22:07:10 pl2 NetworkManager[853]: <info>  [1750277230.8849] device (wlp2s0): state change: activated -> deactivating (reason 'sleeping', managed-type: 'full')
juni 18 22:07:11 pl2 NetworkManager[853]: <info>  [1750277231.1566] device (wlp2s0): state change: deactivating -> disconnected (reason 'sleeping', managed-type: 'full')
juni 18 22:07:11 pl2 NetworkManager[853]: <info>  [1750277231.2679] device (wlp2s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping', managed-type: 'full')
juni 18 22:07:11 pl2 systemd[1]: Starting stop services before sleep...
juni 18 22:07:14 pl2 systemd[1]: Finished stop services before sleep.
juni 18 22:07:14 pl2 systemd-sleep[687615]: Successfully froze unit 'user.slice'.
juni 18 22:07:15 pl2 systemd-sleep[687615]: Performing sleep operation 'hibernate'...
juni 18 22:07:42 pl2 systemd-sleep[687615]: Failed to put system to sleep. System resumed again: Cannot allocate memory
juni 18 22:07:43 pl2 systemd-sleep[687615]: Successfully thawed unit 'user.slice'.
juni 18 22:07:43 pl2 NetworkManager[853]: <info>  [1750277263.5396] manager: sleep: wake requested (sleeping: yes  enabled: yes)

I had very similar issues with my previous laptop (that was stolen 1 year ago) and though the issues was caused by not enough swapspace (24GB ram, 26GB swap), but this laptop with 16GB ram and 30GB swap has a lot more free swap than used ram:

# free && date
               total        used        free      shared  buff/cache   available
Mem:        16097656    12800836     2762240     1263948     2307088     3296820
Swap:       30717948    10006840    20711108
18. juni 22:23:23 +0200 2025

Any suggestions how to figure out what is causing the issue? My previous laptop (identical hardware with the current except for ram and disk) had this issue ever sinse I got it in september 2020.

2

This is my probably not entirely correct very simplified understanding of what happens when hibernating:

When hibernating, the memory contents are written to swap, so that they can be restored again when the system is woken up again.
When there is not enough swap space available - because RAM and specially swap is already used to a high degree - then this is the result.

On suspend, the RAM content is kept alive and the swap content on disk is not altered.
But on hibernation, all that has to be stored somewhere … and when it can’t be, hibernation fails.

Someone please correct me if that is wrong!

1 Like
3

No, that is correct. And judging by what the OP posted, their RAM was pretty full already — only some 3 GiB of free RAM left — and their swap was already 1/3 full as well. So naturally, there isn’t enough available virtual memory for hibernattion.

1 Like
4

If a VM application hasn’t released all memory used, then this will affect the amount of available memory; which in turn can affect swap and the ability to hibernate. This can be true of any application that fails to release memory in a timely fashion.

The cause is clear; as the logs show, “Cannot allocate memory”. You likely need to increase your swap size to compensate for amounts of RAM being used or find a way to clear that memory before you hibernate; probably, both.

Please provide your system information as described (below). :eyes:

Just noting that as well as the overhead from VMs, flatpak and electron-based applications might also contribute to the RAM usage; electron-based in particular are sometimes known to hog memory.

To borrow from a popular trope “it’s all connected”. :alien:

Regards.

System Information

While information from *-fetch type apps might be fine for someone wishing to buy your computer, for Support purposes it’s better to ask your system directly; :eyes:

Output of the inxi command with appropriate parameters will achieve this (naturally, formatted according to forum guidelines) and will generally be more useful for those wishing to help:

inxi --filter --verbosity=8

or the short form:

inxi -zv8
2 Likes
5

I don’t see how 12GB of used ram cannot fit into 20GB of free swap space. Also the hibernate data is supposed to be compressed before writing to disk. There should not be possible to run out of space in this situation.

6

free -h
gives the data in human readable form

for example mine at this very moment:

free -h
               total        used        free      shared  buff/cache   available
Mem:           7,6Gi       2,6Gi       3,7Gi       359Mi       1,9Gi       5,0Gi
Swap:          3,8Gi          0B       3,8Gi

Swap is also already used/occupied and needs to be saved to … that same swap
when hibernating the system.

used RAM + used swap all need to be stored

2 Likes
7

That statement, I’m quite sure is not a fact! Would be pointless to write to swap what already is on swap in order to store it on swap!

My swap is 50% more than the recommended for 16GB of ram with hibernate.

I doubt harddrive space is the issue. Maybe bad sector on disk? Maybe defect ram?

8

Don’t guess. Both are easy to verify (prove). :footprints:
Just because a theory doesn’t fit your needs doesn’t mean it’s actually wrong.

There’s this error message.

I think it’s worth serious consideration:
Failed to put system to sleep. System resumed again: Cannot allocate memory

9

You misunderstand. When hibernating, the contents of the RAM are written to the swap device, but any data that was already in the swap device must also maintain its presence there, so the swap device needs to be able to hold both the contents of your RAM and your already swapped-out data.

As I wrote in post #3, you only had 3 GiB of free RAM left, and your swap partition was already 1/3 filled. In other words, the capacity of your swap device was insufficient to hibernate your system.

1 Like
10

I, however, am. :man_shrugging:

The swap space is used to store what is needed to restore the system state on waking up from suspend.
That is not the same as how the system uses the same space while in operation.

1 Like
11

Yes. So 12 of used ram should not have any trouble to fit into 20GB of free swap.

How does this say anything about the available space for the data needed?

12

How do you test swap space?

13

Look, it’s not that difficult:

10006840 + 12800836 = 22807676

20711108 < 22807676

For the hibernation, the swapped-out RAM is regarded as part of the entire RAM and then also written to the swap as a whole.

Therefore…

To “fix” this, you could deactivate and reactivate the swap:

sudo swapoff /dev/whatever
sudo swapon /dev/whatever

That will free up space.

Or drop some cache:

sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
14

Is there any documentation around telling that what is stored in swap is duplicated into swap at hibernate?

I have a hard time to believe that is the actual behavior. If it was like that, it does not make sense to use the swap partition for hibernate data - if the space is shared with swap, the swap would have to be limited. As there is no mention of such in the guides, that cannot be the case. Also the recommended swap space with hibernate is the size of ram + recommended swap without swap. If the swap would be written twice as some here claim, the recommended swap with hibernate would include another extra swap.

15

Whats the downside of doing this? Would it be a good idea to include either of those commands to run automatically when hibernate is initiated?

16

here is what I think how it works, disclaimer at the end:

RAM and swapped out RAM are combined into one hibernation “image”, which is written to swap and later, on wake up, used to restore the system state.

Only from that image is the system state restored.

When there is not enough space on swap to write that image because swap is already heavily used, the process will, of course, fail.

It’s not the case that the swap content stays as it is and is then used again on wake up - the restoration of the system state is done from the “image” only.

That image is compressed somehow and the compression ratio can be somewhat adjusted via certain settings.
It’s usually smaller than the uncompressed RAM + swap on a live system.
But the amount of space needed for that image needs to be available on swap - in addition to what is already there and which will not be used again.

Then there is a thing called zram and/or zswap - and those already compressed pages will not compress much further, so the image size will not be much smaller …

This is not real knowledge - and much too simplified, but it seems logical to me …

17

My assumption is that at the point of hibernate this happens:

  1. what is in swap stays where it is
  2. what is in ram is piped through a compression algorithm and written to reminding swap space.

The result is that what is written to disk at the point of hibernate is at the most equal to the size of ram. This seems logical to me as the recommended swap with hibernate is exactly the size of ram larger than the recommended size without hibernate, and it is pointless to write data to a place where it already is stored.

18

It is not duplicated. Please try to understand the logic here. When the computer goes into sleep mode, i.e. suspend-to-disk, the state is frozen and then written to the swap as a complete image. RAM and swapped RAM in the swap is a contiguous block, which is also treated as such when the image is written.

This knowledge is rather spread over several articles in the kernel documentation.

Correct. It is advantageous to have 2 swap spaces when using hibernation. One swap file for general swap and one swap partition for suspend-to-disk.

19

and that would almost certainly be a wrong assumption

You are correct that it stays there - in the sense that it is not deleted.
But it is not reused when the system comes back up.

20

So, the best solution would be to split my swap into two partitions and reserve one for hibernate?