We observed a situation where (often in the first 60 seconds of boot) the sqlite3 database would become locked and remain that way until reboot or a full stack_restart. Investigating this (using Chris's show_locks) revealed that ScreenDaemon.py was the process holding the lock on the database.
I looked into this and found that the flask dev server defaults to running in threaded mode since v1.0. When I changed the ScreenDaemon.py run command to _app.run(port=4096, threaded=False), the database lockups stopped happening.
It looks like we aren't accessing the database from ScreenDaemon in a thread-safe manner. Flask has some suggestions on using sqlite3. We may only need to implement an @app.teardown_context.
Another option would be to change to something like SQLAlchemy.
We observed a situation where (often in the first 60 seconds of boot) the sqlite3 database would become locked and remain that way until reboot or a full stack_restart. Investigating this (using Chris's show_locks) revealed that ScreenDaemon.py was the process holding the lock on the database.
I looked into this and found that the flask dev server defaults to running in threaded mode since v1.0. When I changed the ScreenDaemon.py run command to
_app.run(port=4096, threaded=False), the database lockups stopped happening.It looks like we aren't accessing the database from ScreenDaemon in a thread-safe manner. Flask has some suggestions on using sqlite3. We may only need to implement an
@app.teardown_context.Another option would be to change to something like SQLAlchemy.