DB ERROR : MYDELETE is killing our OS X 10.4.2 Tiger Server

[Anonymous]

We upgraded our server from 10.3 to 10.4.2 in July and everything was running great then we started to get an error that no one can quite seem to help with:

Aug 30 11:42:28 www cyr_expire[4576]: DBERROR: mydelete: error deleting <[email protected]>: DB_NOTFOUND: No matching key/data pair found
Aug 30 11:42:28 www cyr_expire[4576]: DBERROR: mydelete: error deleting <[email protected]>: DB_NOTFOUND: No matching key/data pair found
Aug 30 11:42:28 www cyr_expire[4576]: DBERROR: mydelete: error deleting <[email protected]>: DB_NOTFOUND: No matching key/data pair found

As you can see from the time stamp the system creates large log files with this message and the CPU’s max out at 100%. The temporary fix is to stop/start the mail service which is usually good for about 12 hours.

Apple has offered little support for this, if anyone out there knows a fix please let me know. thanks

[maccanada]

cyr_expire handles deletion of expired messages or duplicate deliveries. It’s configured in imapd.conf. You can man cyr_expire for more info. Normallly it’s the client that sets the time span for expiring messages and in your case it looks like it’s trying to expire messages that no longer exist.

Is the message id always the same?

It’s not really a solution, but hopefully I’ve given you something to go on 🙂

[Anonymous]

Yes the messege logged is the same, and if you look at it, it looks like its dated from 2005 07 29 which is about the time we were upgrading the server.

Could you provide a little more information on that or point me to a detailed source. I would love to get this fixed and call Apple and tell them that formatting and reloading was not the answer!

Chris

[Anonymous]

I just googled cyr_expire and read about this guy who is having VERY simular problems. What do you think?

On Sun, 2004-05-30 at 15:16, David Reid wrote:
> I’m running cyrus imap 2.2.3 and have just started experiencing some very
> strange events when cyr_expire runs. It seems to somehow get “hung” in some
> sort of loop and starts eating serious amounts of cpu and then disk space in
> the system and impd logfiles. This results in enormous logfiles and the
> resultant 108% of my /var partition soon causes problems!
>
> It’s possible that cyr_expire isn’t the cause, but the one common factor in
> all instances has been cyr_expire eating cpu. The log files aren’t available
> as I need to delete them to restore the system to a functioning state
>
> Anyone come across this before or have any ideas about what might be causing
> it?

I had a similar issue – cyr_expire would hang indefinitely, causing
quite a few of them to be hanging around after a few days. It turned out
to be deliver db corruption as found by db_verify; nuking the deliver db
did the trick nicely as db_recover couldn’t fix it.

Craig Ringer
***
According to Craig “nuking” the deliver db fixed it for him can anytone confirm this and let me know what to expect.

[Anonymous]

According to the last topic, you can run db_verify and i did and got the following results…
****
www:/var/imap admin$ sudo db_verify deliver.db
db_verify: Page 416: incorrect next_pgno 250 found in leaf chain (should be 28)
db_verify: Page 28: incorrect prev_pgno 17 found in leaf chain (should be 416)
db_verify: Page 136: incorrect next_pgno 17 found in leaf chain (should be 250)
db_verify: Page 250: incorrect prev_pgno 416 found in leaf chain (should be 136)
db_verify: Page 146: last item on page sorted greater than parent entry
db_verify: Page 146: incorrect next_pgno 12 found in leaf chain (should be 24)
db_verify: Page 24: incorrect prev_pgno 56 found in leaf chain (should be 146)
db_verify: Page 12: incorrect prev_pgno 146 found in leaf chain (should be 24)
db_verify: Page 134: first item on page sorted greater than parent entry
db_verify: Page 134: incorrect next_pgno 32 found in leaf chain (should be 98)
db_verify: Page 98: incorrect prev_pgno 22 found in leaf chain (should be 134)
db_verify: Page 98: incorrect next_pgno 59 found in leaf chain (should be 32)
db_verify: Page 32: incorrect prev_pgno 134 found in leaf chain (should be 98)
db_verify: Page 32: incorrect next_pgno 57 found in leaf chain (should be 74)
db_verify: DB->verify: deliver.db: DB_VERIFY_BAD: Database verification failed
www:/var/imap admin$
****

So now the question is what to do with this database. I’m sure there are some problems if you simply Delete it as mentioned above?

Getting closer!

[maccanada]

I’ve never come across this probelm before, so I can’t offer much more help. I’d definitely take a backup before deleting the DB though.

[Anonymous]

Yes, deleting the deliver.db and the db/__*.log files works. I had this problem after moving the database to another disk. I backed up the files but did not need the backup.

Hope this helps someone. It took me two long weekends to figure out.

John D. Trolinger
it at co.kerr.tx.us
Kerr County IT sysadmin, cook, and bottlewasher

I am running cyrus-imapd-2.2.9
syslog Errors were like this:
Jul 28 06:11:44 server cyr_expire[592]: DBERROR: mydelete: error deleting <2062088.1153818115671.JavaMail.Administrator@r1056b-snd12>: DB_NOTF$

Here is what I did:

stop master then

cd /var/imap
rm deliver.db
cd db
rm __db.*

now start master and look at the logs

Log files:

syslog
Jul 29 07:36:51 server lmtpunix[2006]: DBERROR db3: 59 lockers
Jul 29 07:59:27 server master[2077]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted
Jul 29 07:59:27 server master[2077]: retrying with 1024 (current max)
Jul 29 07:59:28 server ctl_cyrusdb[2078]: DBERROR db3: Recovery function for LSN 3 1357975 failed
Jul 29 07:59:28 server ctl_cyrusdb[2078]: DBERROR: dbenv->open ‘/d/mail/var/imap/db’ failed: Operation not permitted
Jul 29 07:59:28 server ctl_cyrusdb[2078]: DBERROR: init() on berkeley

messages
Jul 29 07:57:00 server master[542]: exiting on SIGTERM/SIGINT
Jul 29 07:59:27 server master[2077]: process started
Jul 29 07:59:28 server ctl_cyrusdb[2078]: recovering cyrus databases
Jul 29 07:59:28 server ctl_cyrusdb[2078]: skiplist: recovered /d/mail/var/imap/mailboxes.db (497 records, 10324 bytes) in 3 seconds
Jul 29 07:59:28 server ctl_cyrusdb[2078]: skiplist: recovered /d/mail/var/imap/annotations.db (0 records, 144 bytes) in 0 seconds
Jul 29 07:59:28 server ctl_cyrusdb[2078]: done recovering cyrus databases
Jul 29 07:59:28 server master[2077]: ready for work
Jul 29 07:59:29 server tls_prune[2084]: tls_prune: purged 0 out of 0 entries
Jul 29 07:59:31 server ctl_cyrusdb[2086]: checkpointing cyrus databases
Jul 29 07:59:32 server ctl_cyrusdb[2086]: done checkpointing cyrus databases
Jul 29 07:59:33 server cyr_expire[2085]: duplicate_prune: pruning back 3 days
Jul 29 07:59:33 server cyr_expire[2085]: duplicate_prune: purged 0 out of 0 entries
Jul 29 07:59:33 server cyr_expire[2085]: expunged 0 out of 0 messages from 0 mailboxes

[Author]

Posts