Hi all, A lot of mail does not arrive in my mailbox(es) since I updated ISPConfig last thursday. When I get (incidentaly) a mail I have in error in it X-Virus-Status: Failed X-Virus-Report: /home/admispconfig/ispconfig/tools/clamav/bin/clamscan error 50 X-Virus-Checker-Version: clamassassin 1.2.4 with clamscan / ClamAV 0.93/6832/Fri Apr 18 20:31:07 2008 Also I find some users in my /tmp dir (they receive absoluut no mail) WKR, JL
Hi Till, also not the answer. At some accounts I changes REJECT (spam/virus) in ACCEPT. Now most mail is coming in but with [SPAM] as leading text. I think it has to be a problem in ClamAV 0.93 WKR, JL
Yes, its a problem with Clamav, thats desciribed in the thread I posted above. The error means that the antivirus database is corrupted. Please try to run: rm -rf /home/admispconfig/ispconfig/tools/clamav/share/clamav/* and the: /etc/init.d/ispconfig_server restart this will delete the clamav antivirus database and start the antivirus db download again.
Hi Till, is it also possible to restore the skippped mail which is still in /tmp ? drwx------ 2 cust38_*** web38 4096 Apr 18 21:26 clamav-0ad38ac90ae57f0de295331073d8d694 drwx------ 2 cust38_*** web38 4096 Apr 17 20:45 clamav-0da67ab083ade1be7c6ee81885d06fe2 drwx------ 2 cust38_*** web38 4096 Apr 18 23:17 clamav-23c86779eda99117d5f9171490182ec2 drwx------ 2 cust38_*** web38 4096 Apr 18 21:51 clamav-2f56560a8ac45abdf1245bdde1dc9bec Thanx for so far! WKR, JL
As far as I know, these directories do not contain any mail data, they just contain a temporary copy of the clamav antivirus database. You can delete these directories.
I thought rebuilding ClamAV resolved the problem.... Mail is working again on all accounts accept one... in the message beneath. It keeps writing those DIR's in /tmp I gave them more diskspace, so that can't be the prob The original message was received at Tue, 22 Apr 2008 06:04:54 +0200 from psmtp12.wxs.nl [195.121.247.24] ----- The following addresses had permanent fatal errors ----- "|/usr/bin/procmail -f-" (reason: Can't create output) (expanded from: <info@*****>) ----- Transcript of session follows ----- procmail: Couldn't create "/var/mail/cust38_info32" /bin/cat: write error: Disk quota exceeded procmail: Program failure (1) of "/home/admispconfig/ispconfig/tools/clamav/bin/clamassassin" procmail: Rescue of unfiltered data succeeded procmail: Quota exceeded while writing "/var/www/web38/user/cust38_info32/Maildir/tmp/1208837094.28810_2.******" 550 5.0.0 "|/usr/bin/procmail -f-"... Can't create output Other ideas? WKR, JL
Its defiantely a problem with disk quota. Please set the quota of the user AND website to a higher limit. You can check the quota usage with the command: repquota -avug
I got the same problem. The files in /tmp owned by the mail users and cause over quota error. The -mbox was already not there. Maybe a new problem. Increasing user quota solved this problem but not in a good sense. I found that some clam* folder in /tmp grown up to 40MB within half an hour and aroung 3GB (for 100 users) fulled up with in a few hours. I now temporarily disable quota and still looking for a permanent solution.
Indeed, same here. What I see is, if one of the groupmembers (in my case cust38_*) is over quota, the rest off them follows and all the members of cust38_ become over quota. /tmp is filling with there clamav-* files. There is a grace of 7 days but ... if that works? Is it also possible it ISPConfig wil not measure the logfiles? total of clamav-* is now 2GB I wrote a simple script to stop mailserver + ispconfig --> wait for 20 sec. remove the clamav files from /tmp and restart the progs. This is a temporary workaround till I have the solution. It is spooky... it happans only on one domain. WKR, JL PS on my server are only non-profit orgs from our city - none of them pays for the hosting service. (ia church (cust38 )
The solution is to switch clamav to clamd: http://www.howtoforge.com/forums/showthread.php?t=16204&highlight=clamav+daemon ISPConfig does not mesure the quota itself, it just uses the linux quota system and sets values for the users and groups. If a logfile does noit belong to the group or user of a website, it is nott took into account by the linux quota system. But ISPCononfig has a separate logfile quota mechanism, you can set this quota for the logfiles on the options tab of the site.
I tried to switch to clamd following the instructions in the link Till gave. But I got this error. checking for gcc bug PR28045... configure: error: your compiler has gcc PR28045 bug, use a different compiler, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045 My system is Ubuntu 7.10, the gcc is 4.0.3. Is it the origin of the problem?
Maybe I found something what's usefull. The problem still continues. Yesterday I counted all the mail in the "problem account". The user who is "admin" also gets the total amount of all the mailboxes. There where only 6 messages in this mailbox but the total amount with repquota sais 53Mb. Total of the 16 mailusers was 53Mb and collected to tha account. We gave another account admin rights for that site and now there the 53Mb appeared. as mentioned - old situation: cust38_w***** -- 53588 97280 98304 206 0 0 cust38_inf**** -- 2048 40960 41984 20 0 0 with change of user - over quota cust38_w***** -- 2240 97280 98304 47 0 0 cust38_inf**** +- 53404 40960 41984 6days 179 0 0 after change and gave it a bit more user space cust38_w***** -- 2240 97280 98304 47 0 0 cust38_inf**** -- 53404 256000 257024 179 0 0
Sorry for the late answer Hereby the files of the admin user /var/www/web38 /var/www/web38/phptmp /var/www/web38/log /var/www/web38/log/2006 /var/www/web38/log/2006/12 /var/www/web38/log/2006/12/web.log /var/www/web38/log/2008 /var/www/web38/log/2008/05 /var/www/web38/log/2008/05/web.log /var/www/web38/log/2008/01 /var/www/web38/log/2008/01/web.log /var/www/web38/log/2008/04 /var/www/web38/log/2008/04/web.log /var/www/web38/log/2008/03 /var/www/web38/log/2008/03/web.log /var/www/web38/log/2008/02 /var/www/web38/log/2008/02/web.log /var/www/web38/log/.no_delete /var/www/web38/log/error.log /var/www/web38/log/2007 /var/www/web38/log/2007/10 /var/www/web38/log/2007/10/web.log /var/www/web38/log/2007/08 /var/www/web38/log/2007/08/web.log /var/www/web38/log/2007/12 /var/www/web38/log/2007/12/web.log /var/www/web38/log/2007/05 /var/www/web38/log/2007/05/web.log /var/www/web38/log/2007/01 /var/www/web38/log/2007/01/web.log /var/www/web38/log/2007/09 /var/www/web38/log/2007/09/web.log /var/www/web38/log/2007/07 /var/www/web38/log/2007/07/web.log /var/www/web38/log/2007/04 /var/www/web38/log/2007/04/web.log /var/www/web38/log/2007/11 /var/www/web38/log/2007/11/web.log /var/www/web38/log/2007/03 /var/www/web38/log/2007/03/web.log /var/www/web38/log/2007/06 /var/www/web38/log/2007/06/web.log /var/www/web38/log/2007/02 /var/www/web38/log/2007/02/web.log /var/www/web38/.forward /var/www/web38/user /var/www/web38/user/cust38_info32 /var/www/web38/user/cust38_info32/.spamassassin /var/www/web38/user/cust38_info32/.spamassassin/auto-whitelist /var/www/web38/user/cust38_info32/.spamassassin/bayes_toks /var/www/web38/user/cust38_info32/.spamassassin/bayes_seen /var/www/web38/user/cust38_info32/dead.letter /var/www/web38/user/cust38_info32/Maildir /var/www/web38/user/cust38_info32/Maildir/.customflags /var/www/web38/user/cust38_info32/Maildir/dovecot-uidlist /var/www/web38/user/cust38_info32/Maildir/new /var/www/web38/user/cust38_info32/Maildir/tmp /var/www/web38/user/cust38_info32/Maildir/.INBOX /var/www/web38/user/cust38_info32/Maildir/.INBOX/.imap.index.tree /var/www/web38/user/cust38_info32/Maildir/.INBOX/.imap.index.data /var/www/web38/user/cust38_info32/Maildir/.INBOX/.imap.index /var/www/web38/user/cust38_info32/Maildir/.INBOX/.imap.index.log /var/www/web38/user/cust38_info32/Maildir/cur /var/www/web38/user/cust38_info32/web /var/www/web38/user/cust38_info32/web/index.html /var/www/web38/ssl /var/www/web38/cgi-bin /var/www/web38/web ..... .... .. .
