Inbounds mails do not come to the users mailbox. I see it in the mail spool but the mail never comes to the users accounts. The weird thing is that the server never returns a error message to the sender.
>First, do any emails get delivered to any account? Or are all emails to all >users not being delivered?
All mail, all domains. Looks a external virtualmin error but I cannot find it.
>Second, do you see any errors in /var/log/mail.log when trying to send a message?
>If the messages are sitting in the mail spool, Postfix may be logging an error >into the error log.
Now I send a mail for my gmail account, I see the mail in the mail log and spool but it never comes to the user account.
After some minutes in the spool, the mail disappears without any error message to the sender.
Your clamscan is taking too long to return. But, this shouldn’t result in /dev/null on any new version of Virtualmin (the result from a timeout from the AV test should be delivery in recent versions). I’ve asked Jamie to have a look at this thread, as this would be a bug, if timeouts are still resulting in delivery to /dev/null.
But, to resolve your problem immediately…switch to clamdscan. It’s much faster, and so won’t time out like this.
The latest version of Virtualmin imposes it’s own timeout on clamscan to avoid this problem of it being killed by procmail, but that could fail if the system is so loaded that Virtualmin’s clamd-wrapper.pl never gets a chance to even start.
The simple fix is to edit /etc/procmailrc and add the following line at the top :
[code:1]TIMEOUT=0[/code:1]
The better fix is to run clamd as Joe suggested, which can process email with far less CPU load.
Yes, indeed, I think it’s a bug. My server was just installed and was not overloaded … the problem occurs even if the cpu is idle.
I am not sure that uninstalling clamav is the best option for a webserver. It could be a great idea for us to fill a bug report. DO you use the 32bits or 64bits edition of Debian ?
You have right, uninstalling clamav is not the best option for a webserver. I have installed ASSP (http://assp.sourceforge.net/) in the same server to replace spamassasain/clamav.
One thing to try is running clamd, which responds much faster than clamscan - particularly on Debian, where the stock clamscan package is terribly slow.
I got it !!! In my case, at least, the problem was with clamav : I did a ‘top’ and I saw that a lot of processes of clamd where stuck and used all cpu ressource.
The clamav log file gave me a clue : “ERROR: Can’t lock database directory: /var/lib/clamav/” Each clamd process failed with this error and stayed alive, using more and more cpu.
After googling, I find a topic related to this problem :
After uninstalling the installed version of clamav (0.90.1dfsg-4etch15), I then followed the instructions of mr88talent on Sat Oct 13, 2007 11:47 am that installed the new version (0.94.dfsg.1-1~volatile1) and everything works fine now.
Tristan
What is debian-volatile?
Some packages aim at fast moving targets, such as spam filtering and virus scanning, and even when using updated data patterns, they do not really work for the full time of a stable release. The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. So debian-volatile will only contain changes to stable programs that are necessary to keep them functional.
Yes, using the volatile repo is a very good idea - it’s version of clamav is both more reliable and catches more viruses than the one in the standard debian repo.