The symptom
I wanted to rename a site in BT Panel (the popular Chinese server control panel). So I edited the database directly:
sqlite3 /www/server/panel/data/default.db
update sites set name='example.com' where id=1;The query confirmed the write. I restarted the panel. The UI still showed the old name.
Investigation
First thought: caching. Cleared everything, restarted again, no change.
Then I listed every database file the panel ships with:
find /www/server/panel/data -name "*.db"There were several. More than one of them had a sites table. I had been writing to data/default.db, but the panel was reading from data/db/site.db.
Root cause
The panel migrated its data location across versions. Old files were left in place for compatibility, and a new file became authoritative. Nothing in the UI or the documentation tells you which one is live.
So I was writing to a perfectly valid database that simply was not the one being read. The write succeeded; it just went nowhere.
How to avoid this next time
- Never assume the obvious file name is the live one — check modification times and content before writing
- After a write, verify by reading back through the same channel the application uses
- Prefer the panel's own API or CLI over direct database writes
- When multiple candidates exist, change one and observe whether the UI reflects it — on a test row
The lesson
This is the same pattern as the Cloudflare 526 problem: the system made a choice on my behalf and did not tell me. Silent indirection is the enemy of debuggability.
Comments