GRASS: what to do when the SQLite database becomes busy?

Question

Every now then the SQLite database used internally by GRASS becomes unavailable or locked and the modules do not finish (see example below). This happens with different modules, primarily when manipulating large vectors or vectors with large attribute tables.

What should be the procedure under these circumstances? Is there any way to unblock/unlock the SQLite database?

$ grass /home/lads/GRASSDATA/global/common --exec db.copy from_database=/home/lads/GRASSDATA/global/lads/sqlite/sqlite.db from_table=layers to_table=layers
Cleaning up temporary files...
Starting GRASS GIS...
Executing <db.copy from_database=/home/lads/GRASSDATA/global/lads/sqlite/sqlite.db from_table=layers to_table=layers> ...
WARNING: Busy SQLITE db, already waiting for 10 seconds...
WARNING: Busy SQLITE db, already waiting for 20 seconds...
WARNING: Busy SQLITE db, already waiting for 30 seconds...
WARNING: Busy SQLITE db, already waiting for 40 seconds...
WARNING: Busy SQLITE db, already waiting for 50 seconds...
WARNING: Busy SQLITE db, already waiting for 60 seconds...
WARNING: Busy SQLITE db, already waiting for 70 seconds...
WARNING: Busy SQLITE db, already waiting for 80 seconds...
WARNING: Busy SQLITE db, already waiting for 90 seconds...
WARNING: Busy SQLITE db, already waiting for 100 seconds...
WARNING: Busy SQLITE db, already waiting for 110 seconds...
WARNING: Busy SQLITE db, already waiting for 120 seconds...
WARNING: Busy SQLITE db, already waiting for 130 seconds...
WARNING: Busy SQLITE db, already waiting for 140 seconds...
WARNING: Busy SQLITE db, already waiting for 150 seconds...
WARNING: Busy SQLITE db, already waiting for 160 seconds...
WARNING: Busy SQLITE db, already waiting for 170 seconds...

Answer 1

This situation is caused by a VACCUM operation left behind when the GRASS session ends. For some reason this operation hangs up and blocks any subsequent operations. It is easy to identify the offending process with ps:

$ ps aux | grep sql
duque004  8851  0.0  0.0  32980  1688 pts/2    S    11:49   0:00 db.execute sql=VACUUM
duque004  8852 12.0  0.0  38560  4436 pts/2    S    11:49   0:07 /usr/lib/grass76/driver/db/sqlite
duque004  8906  0.0  0.0  16516  1044 pts/4    S+   11:50   0:00 grep --color=auto sql

Both processes must be forcefully terminated to unblock the database:

$ kill -15 8851 8852
$ ps aux | grep sql
duque004  8935  0.0  0.0  16516  1052 pts/4    S+   11:51   0:00 grep --color=auto sql

Killing these two processes has no impact on the data itself, and afterwards the GRASS session can be restarted without problems.