On Fri, 3 Sep 2004, John LeSueur wrote:
a followup on this post:
i was running some straces on sqlite while it using transactions and think i
may have found the source of the problem, we see this in in the strace output:
... ... close(5) = 0 unlink("/dmsp/moby-1-1/ahoward/shared/silly/db-journal") = 0 ... ...
i think what is happening is
... ... close(5) = 0
here remote client opens db-journal
unlink("/dmsp/moby-1-1/ahoward/shared/silly/db-journal") = 0
I think this file is created everytime you start a transaction. Maybe even if you only perform read only commands.
The journal is what is used to keep track of the changes to the database. Anyone else have any thoughts?
this is, of course, the case. i finally tracked down the cause: in my code i do
begin transaction
get a job from database
fork to run job
update db with pid of job
commit transation
the problem is that the child inherits all the open fds from the 'begin transaction' (sqlite db-journal, etc.). in my case, the child never uses these at all. regardless, when the parent does the unlink the sillyname is created.
the child could attempt to close this fd, but it's difficult for the child to determine which files to close. i think a better solution would be for the sqlite api to set the close-on-exec bit of any files created during a transaction - that way a fork/exec will not inherit all those open files. in fact - it seem as if setting the close-on-exec bit on ALL files the sqlite api opens is the right thing to do since you'd never want them open after an exec right?
thoughts?
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. | --Dogen
===============================================================================
