run0 devoured my disk!

Published: December 13th 2025 (week 50 of 2025)

How I got slapped with a "No space left on device" when trying to run with elevated privileges, and what I did about it. It was a dark and stormy night, raindrops falling down on my windows like bombs on London, and then, suddenly, the status bar of my Sway session changed and some parts of it disappeared... the parts that displayed data fetched with programs run with elevated privileges using run0.

I checked the status of my / filesystem to see if I really did run out of space:

btrfs-filesystem(8) is a wonderful tool

]$ btrfs filesystem usage /

As I suspected, I had several hundred GiB still unallocated. So, what gives?

Turns out that run0 saves a small file in /run/systemd/units/ for every invocation; and if you use ad-hoc unnamed units, the directory will be populated with tens of thousands of those files. Even though each of those is tiny, their combined size grows over time leading to the "No space left on device" problem. You can list those files like this:

]$ ls -1 /run/systemd/units | grep -F 'log-extra-fields'

To avoid this situation use an explicit unit name for your run0 invocations:

]$ run0 --unit=<foo> ...

A log-extra-fields file for the invocation will still be created, but it will always be the same one, since the unit name will not be randomised, so you will not run out of space.

This still leaves the question of what to do about using run0 to enter ad-hoc root-privilege shells: a pseudo-random per-invocation file will still be created, which could lead to the problem. To be honest, I think the simplest solutions are usually the best ones, so putting an alias like

alias shell0="run0 --unit=shell-$(whoami)"

in my .shellrc should be sufficient.

Tags