Hello,
so IMHO there is something wrong with ClamAV itself and also managing its process by SmarterMail. I've started to check how ClamAV works here and there (I have 4 SM gateways which are using ClamAV). I have no clue why sometimes they work and sometimes they dont. For example I was checking on particular system where clamd.exe process just stops during loading. When running clamd.exe from command line with debug attrib I saw something like that:
WARNING: Ignoring deprecated option MailFollowURLs at line 25
LibClamAV debug: searching for unrar, user-searchpath: Standard Windows Paths
LibClamAV debug: sigcheck: Engine enabled
LibClamAV debug: Initialized 0.98.6 engine
LibClamAV debug: Initializing phishcheck module
LibClamAV debug: Phishcheck: Compiling regex: ^ *(http|https|ftp:(//)?)?[0-9]{1,3}(\.[0-9]{1,3}){3}[/?:]? *$
LibClamAV debug: Phishcheck module initialized
LibClamAV debug: Bytecode initialized in JIT mode
LibClamAV debug: Loading databases from C:\....\SmarterMail\Service\Clam\share\clamav
LibClamAV debug: C:\....\SmarterMail\Service\Clam\share\clamav\sigwhitelist.ign2 loaded
LibClamAV debug: in cli_cvdload()
LibClamAV debug: in cli_tgzload()
LibClamAV debug: daily.info loaded
LibClamAV debug: in cli_tgzload_cleanup()
LibClamAV debug: in cli_tgzload()
LibClamAV debug: daily.cfg loaded
LibClamAV debug: Initializing engine->root[0]
LibClamAV debug: Initialising AC pattern matcher of root[0]
LibClamAV debug: cli_initroots: Initializing BM tables of root[0]
LibClamAV debug: Initializing engine->root[1]
LibClamAV debug: Initialising AC pattern matcher of root[1]
LibClamAV debug: cli_initroots: Initializing BM tables of root[1]
LibClamAV debug: Initializing engine->root[2]
LibClamAV debug: Initialising AC pattern matcher of root[2]
LibClamAV debug: Initializing engine->root[3]
LibClamAV debug: Initialising AC pattern matcher of root[3]
LibClamAV debug: Initializing engine->root[4]
LibClamAV debug: Initialising AC pattern matcher of root[4]
LibClamAV debug: Initializing engine->root[5]
LibClamAV debug: Initialising AC pattern matcher of root[5]
LibClamAV debug: Initializing engine->root[6]
LibClamAV debug: Initialising AC pattern matcher of root[6]
LibClamAV debug: Initializing engine->root[7]
LibClamAV debug: Initialising AC pattern matcher of root[7]
LibClamAV debug: Initializing engine->root[8]
LibClamAV debug: Initialising AC pattern matcher of root[8]
LibClamAV debug: Initializing engine->root[9]
LibClamAV debug: Initialising AC pattern matcher of root[9]
LibClamAV debug: Initializing engine->root[10]
LibClamAV debug: Initialising AC pattern matcher of root[10]
LibClamAV debug: Initializing engine->root[11]
LibClamAV debug: Initialising AC pattern matcher of root[11]
LibClamAV debug: Initializing engine->root[12]
LibClamAV debug: Initialising AC pattern matcher of root[12]
LibClamAV debug: Initializing engine->root[13]
LibClamAV debug: Initialising AC pattern matcher of root[13]
LibClamAV debug: daily.db loaded
LibClamAV debug: hashtab.c:Growing hashtable 000000000301F220, because it has ex
ceeded maxfill, old size:64
LibClamAV debug: hashtab.c: new capacity: 128
LibClamAV debug: Table 000000000301F220 size after grow:128
LibClamAV debug: hashtab.c:Growing hashtable 000000000301F220, because it has ex
ceeded maxfill, old size:128
LibClamAV debug: hashtab.c: new capacity: 256
LibClamAV debug: Table 000000000301F220 size after grow:256
LibClamAV debug: hashtab.c:Growing hashtable 000000000301F220, because it has ex
ceeded maxfill, old size:256
LibClamAV debug: hashtab.c: new capacity: 512
LibClamAV debug: Table 000000000301F220 size after grow:512
LibClamAV debug: hashtab.c:Growing hashtable 000000000301F220, because it has ex
ceeded maxfill, old size:512
LibClamAV debug: hashtab.c: new capacity: 1024
LibClamAV debug: Table 000000000301F220 size after grow:1024
LibClamAV debug: hashtab.c:Growing hashtable 000000000301F220, because it has ex
ceeded maxfill, old size:1024
LibClamAV debug: hashtab.c: new capacity: 2048
LibClamAV debug: Table 000000000301F220 size after grow:2048
LibClamAV debug: daily.fp loaded
LibClamAV debug: Loaded 136 filetype definitions
LibClamAV debug: daily.ftm loaded
LibClamAV debug: hashtab.c:Growing hashtable 000000000305A2D8, because it has ex
ceeded maxfill, old size:64
LibClamAV debug: hashtab.c: new capacity: 128
LibClamAV debug: Table 000000000305A2D8 size after grow:128
LibClamAV debug: hashtab.c:Growing hashtable 000000000305A2D8, because it has ex
ceeded maxfill, old size:128
LibClamAV debug: hashtab.c: new capacity: 256
LibClamAV debug: Table 000000000305A2D8 size after grow:256
LibClamAV debug: hashtab.c:Growing hashtable 000000000305A2D8, because it has ex
ceeded maxfill, old size:256
LibClamAV debug: hashtab.c: new capacity: 512
LibClamAV debug: Table 000000000305A2D8 size after grow:512
LibClamAV debug: hashtab.c:Growing hashtable 000000000305A2D8, because it has ex
ceeded maxfill, old size:512
LibClamAV debug: hashtab.c: new capacity: 1024
LibClamAV debug: Table 000000000305A2D8 size after grow:1024
LibClamAV debug: hashtab.c:Growing hashtable 000000000305A2D8, because it has ex
ceeded maxfill, old size:1024
LibClamAV debug: hashtab.c: new capacity: 2048
LibClamAV debug: Table 000000000305A2D8 size after grow:2048
LibClamAV debug: hashtab.c:Growing hashtable 000000000305A2D8, because it has ex
ceeded maxfill, old size:2048
LibClamAV debug: hashtab.c: new capacity: 4096
LibClamAV debug: Table 000000000305A2D8 size after grow:4096
LibClamAV debug: daily.hdb loaded
LibClamAV debug: daily.hdu skipped
LibClamAV debug: daily.idb loaded
LibClamAV debug: daily.ign loaded
LibClamAV debug: daily.ign2 loaded
LibClamAV debug: Ignoring signature Trojan.Generic.Fake.ASISSC
LibClamAV debug: daily.ldb loaded
LibClamAV debug: daily.ldu skipped
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:64
LibClamAV debug: hashtab.c: new capacity: 128
LibClamAV debug: Table 0000000003662CC0 size after grow:128
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:128
LibClamAV debug: hashtab.c: new capacity: 256
LibClamAV debug: Table 0000000003662CC0 size after grow:256
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:256
LibClamAV debug: hashtab.c: new capacity: 512
LibClamAV debug: Table 0000000003662CC0 size after grow:512
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:512
LibClamAV debug: hashtab.c: new capacity: 1024
LibClamAV debug: Table 0000000003662CC0 size after grow:1024
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:1024
LibClamAV debug: hashtab.c: new capacity: 2048
LibClamAV debug: Table 0000000003662CC0 size after grow:2048
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:2048
LibClamAV debug: hashtab.c: new capacity: 4096
LibClamAV debug: Table 0000000003662CC0 size after grow:4096
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:4096
LibClamAV debug: hashtab.c: new capacity: 8192
LibClamAV debug: Table 0000000003662CC0 size after grow:8192
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has ex
ceeded maxfill, old size:8192
LibClamAV debug: hashtab.c: new capacity: 16384
LibClamAV debug: Table 0000000003662CC0 size after grow:16384
LibClamAV debug: hashtab.c:Growing hashtable 0000000003662CC0, because it has exceeded maxfill, old size:16384
LibClamAV debug: hashtab.c: new capacity: 32768
LibClamAV debug: Table 0000000003662CC0 size after grow:32768
LibClamAV debug: Ignoring signature Win.Trojan.5243200
clamd.exe process was stopping without any particular error somewhere where table was 16384 or 32768. I have no idea why but maybe this had something to do with AV DB files because when I've moved files from other SM gateway clamd.exe process started to run correctly (after few tries - ??). Next thing is that SmarterMail was spawning a lot (sometimes A LOT > 20) of clamd.exe processes which was starting and stopping and all of them during startup is using CPU so when we combine 5 or more clamd.exe processes we have 100% CPU usage and when they are starting and stopping we have killed our system. I've decided to change one thing in SmarerMail configuration for ClamAV and it is marking checkbox Remote Server as checked. This should let SM know that I'm managing ClamAV service manually and it should not start any clamd.exe on its own. So I've enabled remote server, opened cmd.exe and runned clamd.exe as a daemon with debug mode on and clamd.conf file. It should work just fine because I have in clamd.conf file:
TCPSocket 3310
TCPAddr 127.0.0.1
and the same values in SM ClamAV remote server configuration but for some reason it is not working. Log file informs:
Mon Apr 20 11:35:25 2015 -> +++ Started at Mon Apr 20 11:35:25 2015
Mon Apr 20 11:35:25 2015 -> clamd daemon 0.98.6 (OS: win32, ARCH: x86_64, CPU: x86_64)
Mon Apr 20 11:35:25 2015 -> Log file size limited to 1048576 bytes.
Mon Apr 20 11:35:25 2015 -> Reading databases from C:\....\SmarterMail\Service\Clam\share\clamav
Mon Apr 20 11:35:25 2015 -> Not loading PUA signatures.
Mon Apr 20 11:35:25 2015 -> Bytecode: Security mode set to "TrustSigned".
Mon Apr 20 11:35:44 2015 -> Loaded 4360151 signatures.
Mon Apr 20 11:35:47 2015 -> TCP: Bound to [127.0.0.1]:3310
Mon Apr 20 11:35:47 2015 -> TCP: Setting connection queue length to 30
that service is running at 127.0.0.1 on port 3310 but delivery logs says something else:
[2015.04.20] 11:36:30 [05571] Unable to run Clam virus checks: System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 127.0.0.1:3310
[2015.04.20] at MailStore.Spam.ClamDClient.CheckStream()
[2015.04.20] 11:36:30 [05572] Unable to run Clam virus checks: System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 127.0.0.1:3310
[2015.04.20] at MailStore.Spam.ClamDClient.CheckStream()
[2015.04.20] 11:36:30 [05573] Unable to run Clam virus checks: System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 127.0.0.1:3310
[2015.04.20] at MailStore.Spam.ClamDClient.CheckStream()
I have no idea why SM is not connecting to ClamAV. I've tried loopback IP, local IP and remote IP. I even unblocked 3310 port on Windows firewall to make sure if this is not an issue here.
Does someone experienced similar issues? I'm using latest builds from http://oss.netfarm.it/clamav/
P.S. Too bad SmarterTrack is not allowing to attach files to posts (another +1 for having previous forum) I would show you screenshot from task manager where multiple clamd.exe processes was starting eating all CPU from system. Another thing is that post writing window is WAAAY to small for big posts writing