[GRASS-dev] Busy SQLITE db

GRASS GRASS developer
1

Hi all,

I'm facing the problem with Busy SQLITE db using GRASS 7.8 in a HPC system.
Reading other problems like that I saw a Metz answer [0] and another
from Luis [1] but I'm not able to fix the problem. Now the mapset is
unusable with vector.

Do you have any idea how to solve the problem and where it come from?

g.remove type=vector name=nuts2_lst_2003_daily -f
Removing vector <nuts2_lst_2003_daily>
WARNING: Busy SQLITE db, already waiting for 10 seconds...
WARNING: Busy SQLITE db, already waiting for 20 seconds...

[0] http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html
[1] https://gis.stackexchange.com/questions/321986/grass-what-to-do-when-the-sqlite-database-becomes-busy

--
ciao
Luca

www.lucadelu.org

2

Ciao Luca,

If you have stale processes e.g. on cluster nodes that have the DB opened this may occur.

Also the file system can have an impact (e.g. writing to an SQLite DB on a CIFS file system from Linux is simply impossible). But that should give a different error message.

So I would look for hanging processes... And you could try to copy the mapset, remove the old one and rename the copy back...

Cheers
Stefan

-----Original Message-----
From: grass-dev <grass-dev-bounces@lists.osgeo.org> On Behalf Of Luca Delucchi
Sent: mandag 4. mai 2020 10:47
To: GRASS-dev <grass-dev@lists.osgeo.org>
Subject: [GRASS-dev] Busy SQLITE db

Hi all,

I'm facing the problem with Busy SQLITE db using GRASS 7.8 in a HPC system.
Reading other problems like that I saw a Metz answer [0] and another from Luis [1] but I'm not able to fix the problem. Now the mapset is unusable with vector.

Do you have any idea how to solve the problem and where it come from?

g.remove type=vector name=nuts2_lst_2003_daily -f Removing vector <nuts2_lst_2003_daily>
WARNING: Busy SQLITE db, already waiting for 10 seconds...
WARNING: Busy SQLITE db, already waiting for 20 seconds...

[0] http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html
[1] https://gis.stackexchange.com/questions/321986/grass-what-to-do-when-the-sqlite-database-becomes-busy

--
ciao
Luca

www.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

3

On Mon, 4 May 2020 at 11:18, Stefan Blumentrath
<Stefan.Blumentrath@nina.no> wrote:

Ciao Luca,

Ciao Stefan,

If you have stale processes e.g. on cluster nodes that have the DB opened this may occur.

first time it happen---

Also the file system can have an impact (e.g. writing to an SQLite DB on a CIFS file system from Linux is simply impossible). But that should give a different error message.

So I would look for hanging processes... And you could try to copy the mapset, remove the old one and rename the copy back...

yes, I would avoid this, but it worked

Cheers
Stefan

--
ciao
Luca

www.lucadelu.org

4

Hi Luca,

On Mon, May 4, 2020 at 10:47 AM Luca Delucchi <lucadeluge@gmail.com> wrote:

Hi all,

I'm facing the problem with Busy SQLITE db using GRASS 7.8 in a HPC system.

Which file system do you use?

Reading other problems like that I saw a Metz answer [0] and another
from Luis [1] but I'm not able to fix the problem. Now the mapset is
unusable with vector.

Do you have any idea how to solve the problem and where it come from?

g.remove type=vector name=nuts2_lst_2003_daily -f
Removing vector <nuts2_lst_2003_daily>
WARNING: Busy SQLITE db, already waiting for 10 seconds...
WARNING: Busy SQLITE db, already waiting for 20 seconds...

Do you use NFS by chance?

ciao,
markusN

[0] http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html
[1] https://gis.stackexchange.com/questions/321986/grass-what-to-do-when-the-sqlite-database-becomes-busy

--
ciao
Luca

www.lucadelu.org

--
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog