/tmp filled up, postfix crashed. are all e-mails accepted now 'toast'?

[fireman949]

Running Zimbra 4.5 OpenSource

For whatever (poor) reason, /tmp was not on its own file system and therefore part of /. There was a period of about 3 hours before a new /tmp file system was created and everything was re-started. In that window, no one has received any e-mails.

We do have a backup MX record in DNS and I've flushed anything out of that server, however it looks like (from the logs) that postfix was receiving e-mails on the zimbra box but not able to process them. Is it possible to re-queue these missing e-mails or are they gone?

Oct 23 18:58:31 server1 postfix/smtpd[18005]: fatal: parameter "smtpd_recipient_restrictions": specify at least one working instance of: check_relay_domains, reject_unauth_destination, reject, defer or defer_if_permit
Oct 23 18:58:32 server1 postfix/master[15707]: warning: process /opt/zimbra/postfix-2.2.9/libexec/smtpd pid 18005 exit status 1
Oct 23 18:58:32 server1 postfix/master[15707]: warning: /opt/zimbra/postfix-2.2.9/libexec/smtpd: bad command startup -- throttling
Oct 23 18:59:32 server1 postfix/smtpd[18035]: fatal: parameter "smtpd_recipient_restrictions": specify at least one working instance of: check_relay_domains, reject_unauth_destination, reject, defer or defer_if_permit
Oct 23 18:59:33 server1 postfix/master[15707]: warning: process /opt/zimbra/postfix-2.2.9/libexec/smtpd pid 18035 exit status 1

[jholder]

Stop zimbra and ps to make sure it's all down.

Then
cat /dev/null > /opt/zimbra/conf/__db.postfix_header_checks.db

And try again.

This might be bug Bug 13951 - After a recover from "disk is full" error, postmap sucks 100% CPU forever

[fireman949]

I checked the bug, and it didn't look related to our issue. We're not currently seeing any error messages in the logs.

We're just missing all the e-mails for the ~3 hours that /tmp (was on /) was full.

Here is our current setup:


/dev/mapper/vg00-root
1.2G 300M 818M 27% /
/dev/sda1 190M 17M 164M 10% /boot
/dev/mapper/vg00-home
992M 34M 908M 4% /home
/dev/mapper/vg00-tmp 5.0G 149M 4.6G 4% /tmp
/dev/mapper/vg00-opt 4.0G 641M 3.2G 17% /opt
/dev/mapper/vg00-zimbra
25G 4.5G 19G 20% /opt/zimbra
/dev/mapper/vg00-ftp 124M 5.6M 113M 5% /srv/ftp
/dev/mapper/vg00-usr 2.4G 1.5G 789M 67% /usr
/dev/mapper/vg00-var 496M 115M 356M 25% /var
/dev/mapper/vg00-var.log
1.5G 447M 936M 33% /var/log



The only thing that was full was /tmp. Since /opt/zimbra was not full, it looks like Zimbra was able to accept mail, but whatever processing it does and uses /tmp for it couldn't complete.