Linking imapd with db-4.1.25

scott at ruralnetwork.net scott at ruralnetwork.net
Fri Jun 13 19:47:19 EDT 2003


QUESTION: 

Does the Berkeley 4.1.25 database not like the version of POSIX threads in 
Linux Mandrake 9.1, but is happy with the NGPT in Redhat 9.0?  I ask because 
when I built Cyrus-IMAP 2.1.12 against the db4.1 libs on Mandrake 9.1, I ran 
into the problem described below: 

///////////////////////////////////////////////////////////// 

On a Mandrkake 9.1 installation on a Athlon system, I configured Berkely 
db-4.1.25NC like so, all on one line: 

env LDFLAGS="-lpthread" ../dist/configure --enable-posixmutexes --enable-cxx 
 --enable-test --enable-rpc --enable-tcl -with-tcl=/usr/lib --prefix=/usr 

I noticed this in the output of configure, though: 

./build_unix/config.log:configure:17731: result: POSIX/pthreads/private 

And subsequently, my build of cyrus-IMAP 2.1.13 linked against this 
db-4.1.25, yielded these messages in /var/log/syslog when I started: 

Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: recovering cyrus databases
Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR db4: Berkeley DB library 
configured to support only DB_PRIVATE environments
Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR: dbenv->open 
'/var/lib/imap/db' failed: Invalid argument 

Looking through the changelog for Berkeley DB 4.1.24, I found: 

2. Support configuration of POSIX pthread mutexes on systems where the 
pthread mutexes do not support inter-process locks. [#4942] 

And then in the Berkeley DB Reference Guide, there is: 

DB_PRIVATE
  Specify that the environment will only be accessed by a single process 
(although that process may be multithreaded). This flag has two effects on 
the Berkeley DB environment. First, all underlying data structures are 
allocated from per-process memory instead of from shared memory that is 
potentially accessible to more than a single process. Second, mutexes are 
only configured to work between threads. 

  This flag should not be specified if more than a single process is 
accessing the environment because it is likely to cause database corruption 
and unpredictable behavior. For example, if both a server application and 
the Berkeley DB utility db_stat are expected to access the environment, the 
DB_PRIVATE flag should not be specified. 

 --
Scott Langley
scott at ruralnetwork.net
Systems Administrator
Rural Network Services




More information about the Info-cyrus mailing list