Lesson 3 of 5
Database Locked / Broken
Concept
SQLite uses a file lock for writes. If a process crashes mid-write, the lock can stick. WAL mode (which your apps use) helps, but sometimes you need to manually check the database integrity.
Emergency commands
# Check if database is healthy
sqlite3 data/mesh.db 'PRAGMA integrity_check;'
# Should say: ok
# Check WAL mode is on
sqlite3 data/mesh.db 'PRAGMA journal_mode;'
# Should say: wal
# Force WAL checkpoint (flush pending writes)
sqlite3 data/mesh.db 'PRAGMA wal_checkpoint(TRUNCATE);'
# If db is corrupted — make a clean copy
sqlite3 data/mesh.db '.dump' | sqlite3 data/mesh_recovered.db
# Check for lock files (shouldn't exist when no process is running)
ls -la data/mesh.db*
# mesh.db, mesh.db-wal, mesh.db-shm are normal with WAL mode
What's happening
WAL mode keeps a separate write-ahead log (
.db-wal). The .db-shm file is shared memory for coordinating readers. Both are normal. If the db is locked and no process is running, delete the -wal and -shm files — SQLite will recreate them.