/tmp filled with clamav files --> user over quota

I read this too, but I was curious to find out what the problem was. I just read that you released ISPConfig 2.2.13 with clamassassin 1.2.4. I will update to this release and see if the problem persists. If it does, I will switch to clamd.

Thanks again for your help!

Grtz,
Arno.

 

The update to 2.2.13 went very smooth, thanks for that. I switched to clamd from debian sarge volatile repo and now everything is fine .

But the "problem" with clamscan remains. Still curious, I tried a clamscan binary from debian sarge (volatile repository) on another server:

server2:~# /usr/bin/clamscan --debug /tmp/
LibClamAV debug: Initializing the engine (0.90.2)
LibClamAV debug: cli_loaddbdir: Acquiring dbdir lock
LibClamAV debug: Loading databases from /var/lib/clamav/
LibClamAV debug: in cli_cvdload()
LibClamAV debug: MD5(.tar.gz) = 3e37be3e4f9f91af1051d70e45078bb0
LibClamAV debug: cli_versig: Decoded signature: 3e37be3e4f9f91af1051d70e45078bb0
LibClamAV debug: cli_versig: Digital signature is correct.
LibClamAV debug: in cli_untgz()
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/COPYING
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.db
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.hdb
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.ndb
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.zmd
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.fp
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.mdb
LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.info
LibClamAV debug: cli_loaddbdir: Acquiring dbdir lock
LibClamAV debug: Loading databases from /tmp/clamav-3c4971bc57d22df681cc975030d56584
...
LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.db loaded
LibClamAV debug: Initializing md5 list structure
LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.hdb loaded
LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.ndb loaded
LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.zmd loaded
LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.fp loaded
LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.mdb loaded
LibClamAV debug: Dynamic engine configuration settings:
LibClamAV debug: --------------------------------------

...

LibClamAV debug: /var/lib/clamav//main.cvd loaded
LibClamAV debug: in cli_cvdload()
LibClamAV debug: MD5(.tar.gz) = aa4b063db525c529b83a795be39ccb30
LibClamAV debug: cli_versig: Decoded signature: aa4b063db525c529b83a795be39ccb30
LibClamAV debug: cli_versig: Digital signature is correct.
LibClamAV debug: in cli_untgz()
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/COPYING
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.db
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.hdb
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.ndb
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.zmd
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.fp
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.mdb
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.info
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.wdb
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.pdb
LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.cfg
LibClamAV debug: cli_loaddbdir: Acquiring dbdir lock
LibClamAV debug: Loading databases from /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.db loaded
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.hdb loaded
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.ndb loaded
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.zmd loaded
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.fp loaded
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.mdb loaded
LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.cfg loaded

...

----------- SCAN SUMMARY -----------
Known viruses: 117716
Engine version: 0.90.2
Scanned directories: 1
Scanned files: 0
Infected files: 0
Data scanned: 0.00 MB
Time: 26.755 sec (0 m 26 s)


It seems to me that clamscan is always using the /tmp directory to store an unpacked version of the main clamav database. After scanning, these files are removed unless the user hasn't enough space (due to quota limits).

Isn't it a good idea to use clamdscan in ISPConfig instead of clamscan? As you mentioned, it is much faster indeed. And nobody would have the quota problem anymore.

Tnx,
Arno

 

Well, thanks again for your replies, it forced me to dig deeper and learn . Please let me know if I can help in some way.

Grtz,
Arno.

 

Mmmmm --- wish I knew this before the upgrade. At least I would have been prepared. Is there some way to exclude the files form the users usages calcs?

At least it not a misconfiguration. thanks for the info.

 

I can delete clamav files in users tmp?

After 2.2.21 update I've a lot of clamav files in user tmp directories.

With 2.2.21 IPSConfig version the new clamav files are in /home/admispconfig/ispconfig/tools/clamav/share/clamav/

Is safe to delete clamav files in users tmp directories?

Thanks!

Regards.

 

You can safely delete them, but it won't solve your problem. As mentioned before use a separate /tmp directory without quota or switch to clamd instead. Take a look at this:

http://www.howtoforge.com/forums/showthread.php?t=16204

Good luck!