Interessting insights!
Dan pointed out, that I should check the locks on the DB files and report
that information back. Unluckily, my 'lsof' just reports PIDs,
executable name
and open file. It is a Busybox multicall binary.
The good thing is: I have 'lslocks' on my system, which gives me
... and here is the solution!
I daemonize my programs using
daemon (1, 1);
If I do that, before I open the DB, then everything is alright,
locks are held - fine!
In the other case I was first opening the DB to fetch some configuration
options from it before I took care of program args and
Interessting insights!
Dan pointed out, that I should check the locks on the DB files and report
that information back. Unluckily, my 'lsof' just reports PIDs,
executable name
and open file. It is a Busybox multicall binary.
The good thing is: I have 'lslocks' on my system, which gives me
On 11/7/62 23:07, Andreas Kretzer wrote:
I'm using SQLITE3 (V3.29.0) on an arm embedded linux (2.6.39) on an ext3
filesystem.
Several processes hold the DB open and the "-wal" and "-shm" files exist.
if I use 'lsof | fgrep ' I can see all processes having all
three
files open. At least one of
I'm using SQLITE3 (V3.29.0) on an arm embedded linux (2.6.39) on an ext3
filesystem.
Several processes hold the DB open and the "-wal" and "-shm" files exist.
if I use 'lsof | fgrep ' I can see all processes having all
three
files open. At least one of the processes uses threads, but every
5 matches
Mail list logo
