Hi Stephen, On Sat, Jul 21, 2007 at 08:51:30PM +0100, Stephen Gran wrote: > This one time, at band camp, Guido Guenther said: > > Hi Stephen, > > On Thu, Jul 05, 2007 at 02:40:46PM +0000, Stephen Gran wrote: > > > We have been using nss-updatedb on alioth (a slightly patched version to > > > temporarily work around a bug in nss-pgsql) and we have noticed that the > > > database updates are not atomic. We frequently get exim panicking that > > > it can't find a user it has just decided to suid to, or svn commits > > > failing, or that sort of thing. > > > > Did you check the return codes of the bdb calls in libnss-db when things > > fail? > > How do I do that? Pointers to docs would be welcome. I'm happy to > write the patch and so on, but I'm just not sure what I'm looking for. Have a look how the database is handled in libnss-db (internal_setent in src/db-open.c). It's simply opened without database environment.
Compare this to nss_cache_init for the DB_VERSION_MAJOR >=4 case in cache.c of nss-updatedb: it first opens the db_environment, creates a db handle and starts the transaction (txn_begin). So (what I think) we should do is to protect the db->get calls in lookup() of libnss-db by transactions and create a proper database environment in internal_setent(). This would (at least I think so) make sure libnss-db sees the "old database content" until the commit of the new content is finished. Docs are at: http://www.oracle.com/technology/documentation/berkeley-db/db/index.html Especially the "Getting started with transaction processing": http://www.oracle.com/technology/documentation/berkeley-db/db/gsg_txn/C/index.html I can cook up a patch during the week if you like, I'd be great having something to test this on though, maybe a chroot or machine that can access alioth's database? Maybe the libnss-db maintainer can should comment on this? Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
