Root partition showing filled because of pulseaudio

I have a 100GB root partition. which is showing as filled, but when I use disk usage analyzers, I can account for only ~50GB.
I deleted some 20GB of old VM images, but then the storage started to fill up again, and in a few minutes the root partition got filled again and now I can account for only ~30GB of data.

After some searching on stackoverflow, I found the command sudo lsof +L1

pulseaudio seems sus.
But I don’t know how to fix this or even how to disable/uninstall/update pulseaudio.

I tried updating, but then I get “Failure writing output to destination

Please help!


your guess might be wrong and there could be another root cause in your system.

However you can disable memfd like this(as root):

$ vi /etc/pulse/client.conf
enable-memfd = no

$ vi /etc/pulse/daemon.conf
enable-memfd = no

and maybe there are conf files in your HOME dir as well.
Check and change:
$ vi $HOME/.config/pulse/*.conf

Monitor again and see if the problem has been gone.

As far as I can tell memfd is more or less harmless but confuses people.
Dont’t forget to reactivate memfd later again if its not the source of your problem.
Just delete the entry in the conf files.

memfd_create() creates an anonymous file and returns a file descriptor that refers to it. The file behaves like a regular file, and so can be modified, truncated, memory-mapped, and so on. However, unlike a regular file, it lives in RAM and has a volatile backing storage. Once all references to the file are dropped, it is automatically released.

So memfd “files” should not take up any storage space on your device.

The flip side of being a regular file (in memory) is that it could be an executable, too.
Then, this hidden process can fill up your disks.

I prefer df -h / for checking free space, and du -h --max-depth=1 / for checking disk usage.

Although on the long run, the most common way to fill the root partition is by updating, as all versions of (previously) installed packages are kept. Cleaning pacman’s cache usually does the trick.

Yes, you are right it was not the problem! There was a 54GB log file from docker that my GUI based disk usage tracker could not access.

Yes, you are right!

sudo du -h --max-depth=1 / did the trick for me, thank you!

I know it was so dumb of me to post this without looking into it properly.
Thank you for your help guys :heart: @flexoron @pobrn @maycne.sonahoz

I’m in a similar situation - where did you find the hidden docker log file?

Doing sudo du -h --max-depth=1 / and looking for the folder which is using high usage, for me it was /var, then doing sudo du -h --max-depth=1 /var and so on to reach the culprit file. In my case, it was at /var/lib/docker/containers/{some_conatiner_id}/.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.