"Error, something went wrong! While executing: attempt to write a readonly database"

I tried to gracefully kill a very very long running grep process associated with updating gravity after updating to the latest version but it appears to have locked the database and left me in a bind. Graceful restarts don't resolve the issue, nor does rebooting the host. Could someone please help me unpick this?

Expected Behaviour:

I should be able to enable Adlists or add new Adlists.

Standard "thick" install on dedicated Linux VM on x86_64 (1 Celeron J1900 core, ~750 MiB RAM, SSD):
-operating system: Debian 11
-hardware: VM

Actual Behaviour:

A pop-up error is displayed;
"Error, something went wrong! While executing: attempt to write a readonly database Added 0 out of 1 adlists"

Debug Token:


Pi-hole version is v5.16.1 (Latest: v5.16.1)
AdminLTE version is v5.19 (Latest: v5.19)
FTL version is v5.22 (Latest: v5.22)

I've tried running pihole -r but it seems to start a gravity update process, which is the very thing I need to avoid in order to change my adlists to smaller ones!

I'll leave it over an hour this time to see if it can complete successfully.

It took hours, but the update process started with pihole -r eventually succeeded. I've been able to make changes to the Adlists again.

It would be nice to be able to cancel the update process, but I guess this is resolved.

There are still problems. I have been able to remove a large list and add a smaller replacement. However when I try to change the group assignment of the new adlist, I get a generic "Error, something went wrong!" pop up message.

There's nothing in the "Pi-hole diagnosis" page.

Updated: https://tricorder.pi-hole.net/9HRRoOPP/

My problem seems related to the discussion here (List handling after recent pi-hole update is exhausting nearly all resources ) . My VM, which is relatively more powerful than the average raspberry pi, was really only getting stuck on the big OIDB list. It doesn't exhaust RAM, but instead seems stuck on I/O wait (the system has an average SSD in it).

I'll try checking for and removing the temp files from that discussion, but the db lock is what's troubling me here.

Thank you

I believe this was resolved by v5.16.2

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