> 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
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
