Cannot write into `/sys/power/mem_sleep` in debian

When using sudo tee or sudoedit, I am getting an Invalid argument error.

sudoedit: unable to write to /sys/power/mem_sleep: Invalid argument
sudoedit: contents of edit session left in /var/tmp/mem_sleep.c9QzrIn7

Even as user root (after su) using vi directly on the file leads to a write error:

"/sys/power/mem_sleep" E514: Write error (file system full?)
WARNING: Original file may be lost or damaged
don't quit the editor until the file is successfully written!

Reloading the file with :e! shows that it is unaltered on the disk. System isn’t full, I can write a file in /usr eg as admin, albeit not in /sys/power.

A previous question with the same symptoms was solved by ensuring the file was written as admin, but here I should have the rights?

>ls -l /sys/power/mem_sleep 
-rw-r--r-- 1 root root 4096 Feb  6 09:03 /sys/power/mem_sleep

Is there some kernel control over the file content, and should it be rewritten with some devoted utility?

This is Debian GNU/Linux 12 (bookworm)

Asked By: Joce


Using vi on that file system entry makes no sense, because it is not a "file on disk", it’s really just a kernel API.

In this case, it’s ab API that only accepts specific strings, and it tells you what things are available on your system. You can’t change that, and you’re writing something that isn’t available on your system, so writing to that file doesn’t work.

I don’t know what you wanted to achieve, so I can give only general pointers:

The interface you’re trying to interact with is documented at .

On any Linux system that isn’t a specifically down-tailored thing for a specific embedded device, you definitely don’t want to interact with this interface yourself – go through your system’s management utilities, which will also tell Userland programs that you’re about to suspend, which can be necessary for many applications, Userland file systems, libusb-based drivers etc. Also, these utilities are simple to use; in the bad olden days it’s just been running pm-suspend, in the slightly less bad days it’s systemctl suspend, which actually makes sure all the components that can break on suspend get informed and asked first.

Answered By: sina bala