Re: [sqlite] File locking to harsh?

2010-02-19 Thread Ian Jackson
Dan Kennedy writes ("Re: [sqlite] File locking to harsh?"):
> According to the linux man page, both EAGAIN and EACCES mean the lock
> could not be obtained due to locks held by other processes. It may mean
> other things too, but it's not clear from the man page how those cases
> can be distinguished from a conflict with another lock. Any suggestions?

I just looked this up in SuSv3 and you are right and I was wrong.
(I think it's insane to get EACCES in this case but it's in the spec
so there you go.)

So, sorry.

Ian.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] File locking to harsh?

2010-02-19 Thread Dan Kennedy

On Feb 18, 2010, at 11:44 PM, Ian Jackson wrote:

> Marian Aldenhoevel writes ("[sqlite] File locking to harsh?"):
>> ~ # sqlite3 /test "create table A (B integer);"
>> Error: database is locked
>>
>> An strace of that command is attached. The problem surfaces here, I  
>> think:
>>
>> open("/test", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
>> ...
>> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET,  
>> start=1073741824,
>> len=1}, 0xbfae5690) = -1 EACCES (Permission denied)
>
> Once again we see sqlite reporting an incorrect error message due to
> (a) not checking errno and (b) not printing errno when reporting the
> error to the user.  This time it's the sqlite3 shell so the sqlite
> developers shouldn't be able wash their hands of it saying it's the
> application's fault.

According to the linux man page, both EAGAIN and EACCES mean the lock
could not be obtained due to locks held by other processes. It may mean
other things too, but it's not clear from the man page how those cases
can be distinguished from a conflict with another lock. Any suggestions?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] File locking to harsh?

2010-02-18 Thread Ian Jackson
Marian Aldenhoevel writes ("[sqlite] File locking to harsh?"):
> ~ # sqlite3 /test "create table A (B integer);"
> Error: database is locked
> 
> An strace of that command is attached. The problem surfaces here, I think:
> 
> open("/test", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
> ...
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, 
> len=1}, 0xbfae5690) = -1 EACCES (Permission denied)

Once again we see sqlite reporting an incorrect error message due to
(a) not checking errno and (b) not printing errno when reporting the
error to the user.  This time it's the sqlite3 shell so the sqlite
developers shouldn't be able wash their hands of it saying it's the
application's fault.

Once again:
 * fcntl F_SETLK failing does not necessarily mean "database is
   locked".  As here, it may mean something else is wrong.  This
   should be reported not as "database is locked" but as "IO error".
 * Reports of IO errors should include the errno value.

Then the user would have got
  Error: IO error: failed to lock database: Permission denied

I would guess that the problem may be due to either the filesystem not
supporting locking (although if the strace hasn't been edited that
seems unlikely for "/test") or perhaps SElinux.

Ian.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] File locking to harsh?

2010-02-16 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marian Aldenhoevel wrote:
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824,
> len=1}, 0xbfae5690) = -1 EACCES (Permission denied)
> 
> I have verified that this is not a mundane issue of access privileges. I
> can open /test in an editor and modify it as I like.
> 
> So apparently something is wrong with that fcntl64-call. Any idea what
> could cause this?

My best guess is that it the underlying filesystem does not support locking.
 The easiest way to verify this is to mount tmpfs somewhere and try on that
that.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt6+tsACgkQmOOfHg372QSaKgCdH8i4J0Pr/crevKyhc95ltpYU
4U0AoKTnAcABOKBOLo+afrqqLZPEmIcb
=RXU0
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] File locking to harsh?

2010-02-16 Thread Marian Aldenhoevel

Hi,

I am trying to use sqlite (3.6.22) on a linux-system that I have built 
from scratch. That system currently uses kernel 2.6.32.8 and is 
ucLibc-based.


The problem I am facing is that sqlite3 cannot lock database files. Any 
statement that needs a lock tells me the database is locked already.


~ # sqlite3 /test "create table A (B integer);"
Error: database is locked

An strace of that command is attached. The problem surfaces here, I think:

open("/test", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
...
fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, 
len=1}, 0xbfae5690) = -1 EACCES (Permission denied)


I have verified that this is not a mundane issue of access privileges. I 
can open /test in an editor and modify it as I like.


So apparently something is wrong with that fcntl64-call. Any idea what 
could cause this?


I feel this is not truly a sqlite3-issue, but as anything else I am 
using this system for is working fine, it is to me :-).


Ciao, MM
~ # strace sqlite3 /test "create table A (B integer);"
execve("/usr/bin/sqlite3", ["sqlite3", "/test", "create table A (B integer);"], 
[/* 12 vars */]) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb77aa000
stat("/etc/ld.so.cache", 0xbfae6e48)= -1 ENOENT (No such file or directory)
stat("/etc/ld.so.preload", 0xbfae7024)  = -1 ENOENT (No such file or directory)
open("/lib/libsqlite3.so.0", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("/lib/libsqlite3.so.0", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("/usr/lib/libsqlite3.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=424608, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb77a9000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220F\0\0004\0\0\0"..., 
4096) = 4096
mmap2(NULL, 425984, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7741000
mmap2(0xb7741000, 416432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 
0xb7741000
mmap2(0xb77a7000, 5536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x66) = 
0xb77a7000
close(3)= 0
munmap(0xb77a9000, 4096)= 0
open("/lib/libdl.so.0", O_RDONLY)   = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9044, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb77a9000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0|\7\0\0004\0\0\0"..., 
4096) = 4096
mmap2(NULL, 16384, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb773d000
mmap2(0xb773d000, 4920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 
0xb773d000
mmap2(0xb773f000, 4144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 
0xb773f000
close(3)= 0
munmap(0xb77a9000, 4096)= 0
open("/lib/libc.so.0", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=285328, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb77a9000
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\224\251\0\0004\0\0\0"..., 
4096) = 4096
mmap2(NULL, 307200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76f2000
mmap2(0xb76f2000, 280032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 
0xb76f2000
mmap2(0xb7737000, 5175, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x44) = 
0xb7737000
mmap2(0xb7739000, 15884, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7739000
close(3)= 0
munmap(0xb77a9000, 4096)= 0
open("/lib/libdl.so.0", O_RDONLY)   = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9044, ...}) = 0
close(3)= 0
open("/lib/libc.so.0", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=285328, ...}) = 0
close(3)= 0
open("/lib/libc.so.0", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=285328, ...}) = 0
close(3)= 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=21096, ...}) = 0
mprotect(0xb773f000, 4096, PROT_READ)   = 0
mprotect(0xb7737000, 4096, PROT_READ)   = 0
mprotect(0xb77b, 4096, PROT_READ)   = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigaction(SIGINT, {0x804e4c5, [INT], SA_RESTORER|SA_RESTART, 0xb76fc99b}, 
{SIG_DFL, [], 0}, 8) = 0
access("/test", F_OK)   = 0
brk(0)  = 0x8053000
brk(0x8054000)  = 0x8054000
stat64("/test", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/test", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
_llseek(3, 0, [0], SEEK_SET)= 0
rea