Cyrus-IMAP Logging region out of memory thing

One Wednesday morning, our email users reported that they are not receiving any emails, which is very unusual for a very busy day. I found out that the Cyrus-IMAP's database is flagging with errors as below:

[root@mail ~]# tail -n 100 -f /var/log/maillog

Mar 24 10:36:14 mail lmtpunix[4017]: executed
Mar 24 10:36:14 mail lmtpunix[4017]: DBERROR db4: Logging region out of memory; you may need to increase its size
Mar 24 10:36:14 mail lmtpunix[4017]: DBERROR: opening /var/lib/imap/deliver.db: Cannot allocate memory
Mar 24 10:36:14 mail lmtpunix[4017]: DBERROR: opening /var/lib/imap/deliver.db: cyrusdb error
Mar 24 10:36:14 mail lmtpunix[4017]: FATAL: lmtpd: unable to init duplicate delivery database
Mar 24 10:36:14 mail master[4664]: process 4017 exited, status 75
Mar 24 10:36:14 mail master[4664]: service lmtpunix pid 4017 in READY state: terminated abnormally
Mar 24 10:36:14 mail master[4018]: about to exec /usr/lib/cyrus-imapd/lmtpd

It turned out that the Cyrus-IMAP service runs out of log memory. So here comes the need to change the default setting and create a bigger cache and log memory regions of Cyrus-IMAP's database as documented below.

Changing the default Logging region of Cyrus-IMAP servers database is easy.

Create a DB_CONFIG file is you have not done it yet.

[root@mail ~]# cat > /var/lib/imap/db/DB_CONFIG 

set_cachesize 0 2097152 1

set_lg_regionmax 1048576

^D

Stop the cyrus-imapd server, this is very important.

[root@mail ~]# /etc/init.d/cyrus-imapd stop

Backup the database to be recovered.

[root@mail ~]# rsync -auvp /var/lib/imap/db /root/db_backup.date

Recover the database that was changed.

[root@mail ~]# db_recover -h /var/lib/imap/db

Once the command above is successfully done, we can now start the Cyrus-IMAP service.

[root@mail ~]# /etc/init.d/cyrus-imapd start

Check the new cache and memory statitics and wether the new settings are set correctly.

[root@mail ~]# db_stat -h /var/lib/imap/db -m

[root@mail ~]# db_stat -h /var/lib/imap/db -l

Shoot a few emails and check the logs how it goes. If users are no receiving emails correctly, the server is now back online. Keep monitoring until you are certain that everything is now back to normal.