This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Alexey Shamrin shamrin at gmail.comHi Holger, On Fri, Feb 21, 2014 at 4:53 PM, Holger Hans Peter Freyther <holger at freyther.de> wrote: > the answer right now is really not to access the database/tables from outside. Thank you! I was under impression that OpenBSC was locking *itself* from database file. But this is obviously wrong, OpenBSC is single-threaded. I now know there was another script periodically querying SQLite file. That said, it's not practical to never touch DB from outside and use only OpenBSC VTY interface. The latter doesn't allow custom SQL queries. Fortunately, the workaround is simple: issue `PRAGMA journal_mode = WAL` from `sqlite3` command once, when deploying OpenBSC. > So the "fix" is really just a workaround and WAL does not come for free either. As far as I can tell, most disadvantages of WAL [1] don't concern OpenBSC. Possibly except the need to have write privileges to DB directory in order to read from WAL database. > In case you want to improve the database code please have > a look here[1]. In the long run our interface should be async, we should > use the DB APIs directly, use prepared statements, etc. > [1] http://openbsc.osmocom.org/trac/wiki/Tasks/NITBAsyncDatabase Yes, but switching the async interface alone won't fix the 'database is locked' problem. Only if we also switch to MySQL/Postgres. What do you mean by "use the DB APIs directly"? [1]: https://www.sqlite.org/draft/wal.htm Alexey