The error you are seeing in the Asterisk CLI is due to an app not properly handling concurrent use of the AstDB (SQLite 3 database). When synchronizing the AstDB HAAst will briefly lock the database (with a SQL lock), at which point apps should queue their commands until the lock is released.
Most properly designed apps respect concurrency by checking for the lock, then either blocking or retrying for a period of time, to acquire the lock. An overly simplistic application might not check for a lock, and simply report an error (“database is locked”) following an attempt to write. We have seen this error before with FreePBX and a couple of open source Asterisk add ons.
Although the proper solution involves asking the app developer to correct their code, we realize that some developers have no interest in doing so (or become hostile if you suggest anything is wrong with their code). So until the developer in question fixes their code, we do offer a workaround.
Create an Asterisk pre-start event handler (/usr/local/haast/events/asterisk.start.pre) in HAAst containing the following code:
#!/bin/bash
sqlite3 /var/lib/asterisk/astdb.sqlite3 “PRAGMA journal_mode=wal”;
This will enable the “WAL” feature of SQLite3 – which effectively prevents reader and writer processes from locking each other out of the database. You can also issue this command from any bash prompt and you should see the response “wal”. If you don’t see this respnose, repeat the command every 10 seconds until “wal” is returned. (The command can fail if the database is already locked).
