/dev/shm full due to amavisd

[lilwong]

Hi,

Some time today we stopped receiving mails. A further check concluded that /opt/zimbra/amavisd-new-2.3.3/tmp filled up /dev/shm to the brim. I immediately moved half of the folders there elsewhere and restarted zimbra. It took some time to clear all the mails in the queue but we can receive emails again.

Problem is, the folder size of /opt/zimbra/amavisd-new-2.3.3/tmp has remained stagnant ever since the restart. What are those files for? And why aren't they being cleared. Since amavisd is the virus scanner, I would assume that those are files in the queue for scanning. I would also like to know whether I should move back the files I moved previously.

Also, how do I increase the tmpfs partition size for /dev/shm?

thanks!
wong

[lilwong]

hi,

I just modified the /etc/fstab and pushed the partition size for /opt/zimbra/amavisd-new-2.3.3/tmp to 500MB (half my available RAM). Have already remounted it. Is that a good move? And will this setting persist through zimbra restarts?

thanks
wong

Originally Posted by lilwong

Hi,

Some time today we stopped receiving mails. A further check concluded that /opt/zimbra/amavisd-new-2.3.3/tmp filled up /dev/shm to the brim. I immediately moved half of the folders there elsewhere and restarted zimbra. It took some time to clear all the mails in the queue but we can receive emails again.

Problem is, the folder size of /opt/zimbra/amavisd-new-2.3.3/tmp has remained stagnant ever since the restart. What are those files for? And why aren't they being cleared. Since amavisd is the virus scanner, I would assume that those are files in the queue for scanning. I would also like to know whether I should move back the files I moved previously.

Also, how do I increase the tmpfs partition size for /dev/shm?

thanks!
wong

[KevinH]

You can if you want move it to a physical disk but you'll lose some perf.

[brian]

This issue is somewhat known and is being tracked via bug 8081.

[shanson]

Something similar just happened to us. A well-compressed tar file expanded to fill the entire 150MB tmpfs partition, amavisd stopped accepting mail, and thus nothing could be delivered or sent.

Sep 20 18:34:28 otto amavis[26201]: (26201-01) (!) ESMTP ABORTING: Can't write to mail file: No space left on device at (eval 56) line 584, <GEN4> chunk 91.
Sep 20 18:34:28 otto amavis[26201]: (26201-01) (!) ESMTP: NOTICE: ABORTING the session: Can't write to mail file: No space left on device at (eval 56) line 584, <GEN4> chunk 91.
Sep 20 18:34:36 otto amavis[26209]: (26209-01) (!!) ESMTP TROUBLE: 451 4.5.0 Can't flush mail file: No space left on device at (eval 56) line 619, <GEN4> line 76.

Maybe the amavisd-new parameter "$MAX_EXPANSION_QUOTA = 300*1024*1024" is somewhat too large when the tmpfs partition is only 150MB.