I found out it happens when the file system /run/knot-resolver is full.

OK, we could try improving diagnostics for such common situations.

It seems like /run/knotresolver/ruledb/data.mdb becomes very large. I
have about 60 MB of RPZ	files, of which the largest one is this:
https://github.com/hagezi/dns-blocklists/blob/main/rpz/tif.txt

Yet, 256 MB of tmpfs is not enough for /run/knot-resolver and then it
will end up in a loop.

When loading that RPZ afresh, it takes 85 MiB.  (du -hs /run/knotresolver/ruledb/data.mdb)

That's if you delete that file before loading. But for smooth reload we use transactions, and as we don't know what's changed in a file and other settings, we load everything anew. Compounded with non-ideal management of free space in LMDB, I see about 3x this initial size used when using a system continuously. E.g. a quick experiment, reloading with just this RPZ a few times, the du-size converges to 254 MiB.

I certainly do plan to look into making this more RAM-efficient at some point in future. Not that contrary to resolver before 6.0, this space is shared by all workers, not multiplied by their number.

--Vladimir