Just to make sure, you didn't oversee that (like I was ...):
Daemonizing a process is also a fork() - and this invalidates
your connection!
I used the daemon() function in my program (together with a
few other processes) that used a DB connection. I opened
this connection _before_ I called daemon() and everything seemed
right. But as soon, as the other processes terminated, the lock
and WAL files went away, and everything I did with the DB didn't
reach the actual files. After that, the DB image was damaged.
Andreas
Am 11.11.2019 um 18:37 schrieb Simon Slavin:
On 11 Nov 2019, at 5:13pm, Jukka Marin <jukka.ma...@jmp.fi> wrote:
The main process first opens the databases and checks that their
version matches that of the software and if not, the databases are
closed and initialized by running a script.
After closing the databases, main process forks the children and
all processes (including main process) open the databases and use
their own connections.
What I was trying to ask was this: If any of the children dies
(a bug in the code), main process will restart the child. At
this point, the main process has the databases open, so the new
child receives the connections as well. What should I do now?
Okay, that gives us enough information to work with.
The conservative way to do it is to have the main process close the connection
before forking and open it again. Then, of course, the child processes make
their own connections.
But I don't think that's necessary. A child process can have access to the
main process' database connection but ignore it. So I think the main process
can fork without closing its connection. Then each child can never use that
one but instead make its own.
Of course, every one of these connections needs to set a timeout. And every
call to the SQLite3 library needs to check its result code and make sure it is
getting SQLITE_OK (or, for queries, SQLITE_DONE etc.).
Should the child close the databases before opening them again?
Will this close the databases for the main process as well?
As you suspected, closing the connection releases both memory structures and
file handles. Anything that tries to use that connection will then fail
because it has no idea what it's talking to.
What puzzles me is this: you're getting "database malformed" and nothing you've
described justifies this. Assuming that this isn't just one old database which is
genuinely corrupt, but that you are using a fresh uncorrupt database each time, you seem
to have a genuine bug in your code.
This happens mostly because something is stomping on the memory assigned to a
connection. In your case, this probably means something is stomping on the
memory assigned to one of the child processes.
So, first write yourself a quick script to use the shell tool to check the
database for corruption. Then run that, even while your program is running,
and see if you can figure out whether your database really is corrupt or
whether your program is getting spurious error messages.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
--
Mit freundlichen Grüßen
Andreas Kretzer
ETB Electronic Team
Beratungs- und Vertriebs GmbH
Berliner Straße 8a
15537 Erkner
FON +49 3362 889349-12
FAX +49 3362 889349-23
email: a.kret...@etb-electronic.de
AG Potsdam HRB 16532; Sitz der Gesellschaft: Am Mellensee
Geschäftsführer: Wolfgang A. Runge, Marco Runge, Jürgen Gentzsch
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
