[gridengine users] [SGE+sqlite3] Error: database is locked

Pierre Lindenbaum pierre.lindenbaum at univ-nantes.fr
Fri Nov 23 10:14:09 UTC 2012


I'm still investigating my problem of sqlite3/SGE.
It seems that sqlite3 doesn't work in my shared directory.


I've logged as root on a node of the cluster. The simple following 
command fails: (/commun/data/stats2.sqlite doesn't exist)

    ssh root at node02
    root at node02's password:
    [root at node02 ~]# sqlite3 /commun/data/stats2.sqlite 'create table if 
not exists timeBeginDB(target text UNIQUE NOT NULL,inserted int);'
    Error: database is locked

it works in ~root:

     [root at node02 ~]# sqlite3 stats2.sqlite 'create table if not exists 
timeBeginDB(target text UNIQUE NOT NULL,inserted int);'
     [root at node02 ~]#

I cannot find a resource saying that sqlite doesn't work with NTFS

Pierre

PS: cross posted on SO: http://stackoverflow.com/questions/13525235

>> Am 22.11.2012 um 17:24 schrieb Pierre Lindenbaum:
>>
>>> I'm trying to run a script that fills a sqlite3 database.
>>>
>>> The script creates a lock with `lockfile` , fills the database and
>>> releases the lock.
>>>
>>>   $cat test.sh
>>>
>>>   #!/bin/sh
>>>   lockfile /commun/data/_tmp.idp448.lock
>>>   sqlite3 /commun/data/stats.sqlite "create table if not exists
>>> timeBeginDB(target text UNIQUE NOT NULL,inserted int);"
>>>   rm -f /commun/data/_tmp.idp448.lock
>>>   whoami
>> Is "/commun/" shared between all nodes?
> yes.
>
> furthermore, *lockfile* is able to create the file
> /commun/data/_tmp.idp448.lock
> even when the script is called with 'qsub'
>
> the lock file is later deleted with rm -f
>
> only the call to sqlite3 prints an error message.
>
>>> without qsub the script works without any problem :
>>>
>>>   [lindenb]$ sh test.sh
>>>   lindenb
>>>
>>> when qsub is invoked:
>>>
>>>   $ qsub -cwd -S /bin/sh test.sh
>>>   Your job 673 ("test.sh") has been submitted
>>>
>>>   $ cat test.sh.o673
>>>   lindenb
>>>
>>>
>>> $ cat test.sh.e673
>>> Error: database is locked
>>>
>>>
>>> which is a sqlite3 error.
>>>
>>> Do you have any idea, suggestion of what, on the SGE side, could be the
>>> cause of that problem, this difference of behavior ?
>> Is the lockfile you define "_tmp.idp448.lock" in any way related to the
>> database?
> no, it's a random name  I've created.  This file is here to ensure that
> only one process is accessing the sqlite3 database.
>
> I'm the only one here playing with the cluster: so nobody can create the
> file on open the sqlite database at the very same time.
>
>> Maybe the output is not telling the truth.
>>
>> On the command line it runs local, but if it's submitted on any machine in
>> the cluster. Also the environment might miss some settings which are
>> present on the command line.
> all the nodes have been installed using 'yum install sqlite3' so I guess
> there is nothing to configure.
>
> Thank your  for your help.
>
> Pierre
>
>
>
>
>
>



More information about the users mailing list