Sorry it has taken me to so long to reply. I want to thank everyone for your help on both cases. I do have a further question on the log rotation part.
I added: set_flags DB_LOG_AUTOREMOVE to the DB_CONFIG file. When I restarted the daemon, I did not see any difference in the number of log.* files. Since I rebuilt the db yesterday, the only log.* file to be modified when I restarted it today was the last one numerically speaking. I am guessing, since this particular ldap port has not had any activity except some reads, that 1) only the last log would be modified since restarting 2) the number of logs I have would always start with this much whenever I rebuild (slapcat/slapadd) 3) to see more logs, then more activity would have to happen and then I would start to see some logs be removed. Is this right? Also, reading in the documentation: http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE It notes: "If set, Berkeley DB will automatically remove log files that are no longer needed. Automatic log file removal is likely to make catastrophic recovery impossible." So, I worry. Is there a way to reduce the number of log files and be able to be safe against catastrophic problems? I am guessing the only way to do this is to rebuild the db from scratch via slapcat/slapadd? Thanks for any help! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Horsfall Sent: Tuesday, January 30, 2007 11:13 PM To: OpenLDAP Software List Subject: Re: cleaning up logs from bdb db and upgrading ldap On Tue, 30 Jan 2007, Howard Chu wrote: > > Only when upgrading between major versions e.g. 2.2.X -> 2.3.X. > > Technically that is the minor version number. I.e., an OpenLDAP release > number is major.minor.patch. In the 2.x releases we've had database > format changes for each minor release thus far, but probably won't have > any format changes in 2.4. > > And actually, the format only changed between 2.2 and 2.3 for > little-endian machines like Intel x86. On big-endian machines like > Sparc, there was no change. Now we consistently use big-endian byte > order everywhere. Corrections noted; thanks. -- Dave Horsfall DTM VK2KFU [EMAIL PROTECTED] Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
