Community Discussions and Support
ClamWall starts many instances of ClamD and FreshClam

I had the same problem when I recently upgraded to 4.52 and found that if I disabled the "Exit and restart each day after performing daily maintenance" option the problem went away.  I had originally used this setting because 4.01b seemed to have a memory leak on my XP installations which caused Mercury to freeze up after a couple of days.  I haven't yet had this problem with 4.52.  So, that might be something to check.

I had the same problem when I recently upgraded to 4.52 and found that if I disabled the "Exit and restart each day after performing daily maintenance" option the problem went away.  I had originally used this setting because 4.01b seemed to have a memory leak on my XP installations which caused Mercury to freeze up after a couple of days.  I haven't yet had this problem with 4.52.  So, that might be something to check.

After successfully upgrading from Mercury/W32 v4.01b to v4.51 I tried to install ClamAV and after I got it to run together with ClamWall I got a new problem:

ClamAV is installed on the same machine as Mecrury - thats why I use the option  "ClamAV daemon is started and controlled by Mercury" in the ClamWall config window. ( in clamwall.ini: [ClamAV] ClamSelf=1 )

And now, whe I look in the clamwall log, I see that each incoming mail starts a new instance of clamd.exe and freshclam.exe. In the taskmanager I saw more than 20 processes "freshclam.exe". What's wrong here ?

After changing to "External ClamAV daemon" in the ClamWall config and manually starting clamd.exe it works fine - but this is not the option explained in the ClamWall manual [:(]

Can anybody  explain that to me ?

Kind regards,
Thomas
 

<p>After successfully upgrading from Mercury/W32 v4.01b to v4.51 I tried to install ClamAV and after I got it to run together with ClamWall I got a new problem:</p><p>ClamAV is installed on the same machine as Mecrury - thats why I use the option  "ClamAV daemon is started and controlled by Mercury" in the ClamWall config window. ( in clamwall.ini: [ClamAV] ClamSelf=1 )</p><p>And now, whe I look in the clamwall log, I see that each incoming mail starts a new instance of clamd.exe and freshclam.exe. In the taskmanager I saw more than 20 processes "freshclam.exe". What's wrong here ?</p><p>After changing to "External ClamAV daemon" in the ClamWall config and manually starting clamd.exe it works fine - but this is not the option explained in the ClamWall manual [:(]</p><p>Can anybody  explain that to me ?</p><p>Kind regards, Thomas  </p>

Hello Thomas,

I am not able to explain the behaviour of ClamAV when controlled by Mercury but I can confirm that the multiple instances of Clam are the result when using that option. I have tried it on several Mercury servers, always with the same result. If enough emails arrive then the CPU utilisation tops out and memory starts to go down. I have set all my Mercury servers to use the external ClamAV daemon and they are all working well. If you start the Freshclam exe with the -d switch it will remain loaded and will check for updates as frequently as the setting in the Freshclam.conf file tells it to. I have set mine to 9 hours so that the checks drift throughout the day to avoid hitting the Clam servers at busy times.

 I hope this helps.

Regards,

Terry
 

<p>Hello Thomas,</p><p>I am not able to explain the behaviour of ClamAV when controlled by Mercury but I can confirm that the multiple instances of Clam are the result when using that option. I have tried it on several Mercury servers, always with the same result. If enough emails arrive then the CPU utilisation tops out and memory starts to go down. I have set all my Mercury servers to use the external ClamAV daemon and they are all working well. If you start the Freshclam exe with the -d switch it will remain loaded and will check for updates as frequently as the setting in the Freshclam.conf file tells it to. I have set mine to 9 hours so that the checks drift throughout the day to avoid hitting the Clam servers at busy times.</p><p> I hope this helps.</p><p>Regards,</p><p>Terry  </p>

Hello Terry,

thank you for your answer.
As I wrote above I have done the same - setting ClamWall to "External ClamAV  daemon" and running ClamAV on the same machine. It sounds somewhat curios, because it's not an "external" daemon, but it works.

But if this is a general problem, that do not concern only my installation, someone should report this to David and to Lukas Gebauer too.

Meanwhile I have found one more bug in ClamWall:
If you enable reporting ("Report bans back to the message sender") ther is a problem in resolving the senders address.

May be the senders from: is "Jim Tonic" <jimtonic@bartenders.com> and the mail has no virus but a banned attachment (.pif, .lnl, .exe). One reporting mail is correctly sent to jimtonic@bartenders.com but ClamWall will send the same mail to the address Jim Tonic, what results in an error message to the postmaster "User Jim Tonic not known at this site."

Regards,
Thomas 

 

&lt;p&gt;Hello Terry,&lt;/p&gt;&lt;p&gt;thank you for your answer. As I wrote above I have done the same - setting ClamWall to &quot;External ClamAV&amp;nbsp; daemon&quot; and running ClamAV on the same machine. It sounds somewhat curios, because it&#039;s not an &quot;external&quot; daemon, but it works.&lt;/p&gt;&lt;p&gt;But if this is a general problem, that do not concern only my installation, someone should report this to David and to Lukas Gebauer too.&lt;/p&gt;&lt;p&gt;Meanwhile I have found one more bug in ClamWall: If you enable reporting (&quot;Report bans back to the message sender&quot;) ther is a problem in resolving the senders address. &lt;/p&gt;&lt;p&gt;May be the senders from: is &lt;b&gt;&quot;Jim Tonic&quot; &amp;lt;jimtonic@bartenders.com&amp;gt; &lt;/b&gt;and the mail has no virus but a banned attachment (.pif, .lnl, .exe). One reporting mail is correctly sent to &lt;b&gt;jimtonic@bartenders.com &lt;/b&gt;but ClamWall will send the same mail to the address &lt;b&gt;Jim Tonic&lt;/b&gt;, what results in an error message to the postmaster &quot;User Jim Tonic not known at this site.&quot;&lt;/p&gt;&lt;p&gt;Regards, Thomas&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Multiple processes with clamd.exe and freshclam.exe is not a general problem. We get one of each, and they start and stop nicely together with Mercury/32. I'm not sure what could be causing the problem, but one thing we noticed during setup was that clamd wasn't happy with the path to the conf file in ClamWall so we had to make a copy of the file in the path that's hardcoded into the exe-file.

 /Rolf
 

&lt;p&gt;Multiple processes with clamd.exe and freshclam.exe is not a general problem. We get one of each, and they start and stop nicely together with Mercury/32. I&#039;m not sure what could be causing the problem, but one thing we noticed during setup was that clamd wasn&#039;t happy with the path to the conf file in ClamWall so we had to make a copy of the file in the path that&#039;s hardcoded into the exe-file.&lt;/p&gt;&lt;p&gt;&amp;nbsp;/Rolf &amp;nbsp;&lt;/p&gt;

Hello Rolf,

I tried several paths for clamd and freshclam files and the .conf files -  no way to chance the behaviour of starting multiple instances. May be the problem is concerned to the frequency of incoming mails ? The first incoming mail starts clamd and freshclam - and if the next mail is coming before scanning the first mail is done and freshclam is ready, clamd and freshclam will be started again And after many fast incoming mails I got error messages in clamd.log and found many instances of frehclam in the task manager.

If it works in your configuration, can you have a look in the clamwall log an tell me, how often freshclam is started ?

Regards
Thomas
 

&lt;p&gt;Hello Rolf,&lt;/p&gt;&lt;p&gt;I tried several paths for clamd and freshclam files and the .conf files -&amp;nbsp; no way to chance the behaviour of starting multiple instances. May be the problem is concerned to the frequency of incoming mails ? The first incoming mail starts clamd and freshclam - and if the next mail is coming before scanning the first mail is done and freshclam is ready, clamd and freshclam will be started again And after many fast incoming mails I got error messages in clamd.log and found many instances of frehclam in the task manager.&lt;/p&gt;&lt;p&gt;If it works in your configuration, can you have a look in the clamwall log an tell me, how often freshclam is started ?&lt;/p&gt;&lt;p&gt;Regards Thomas &amp;nbsp;&lt;/p&gt;

Interesting. I have always used clamself mode, but I am not seeing exactly the same problem.

My logs show restarts for every message, but I only have one instance of clamd and freshclam.  This started happening some time ago - when I upgraded to Mercury v4.51.  It is not an issue when I revert to v4.01c.

I will see what happens after a Clamav upgrade and make some other changes.

Config: Clamav (tBB dev version); Clamwall 1.1.4.78 Clamself, windows not hidden; NT4sp6 server

(Note that the Clamwall version which was bundled with v4.51 may not be the latest.)

&lt;P&gt;Interesting. I have always used clamself mode, but I am not seeing exactly the same problem.&lt;/P&gt; &lt;P&gt;My logs show restarts for every message, but I only have one instance of clamd and freshclam.&amp;nbsp; This started happening some time ago -&amp;nbsp;when I upgraded to Mercury v4.51.&amp;nbsp; It is not an issue when I revert to v4.01c.&lt;/P&gt; &lt;P&gt;I will see what happens after a Clamav upgrade and make some other changes.&lt;/P&gt; &lt;P&gt;Config: Clamav (tBB dev version); Clamwall 1.1.4.78 Clamself, windows not hidden; NT4sp6 server&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;(Note that the Clamwall version which was bundled with v4.51 may not be the latest.)&lt;/P&gt;

As Rolf Lindby already mentioned, the ClamSelf mode requires the clamd.conf config file to be in the clamav\bin directory. That should solve the restart errors.

Best regards

Nico

As Rolf Lindby already mentioned, the ClamSelf mode requires the clamd.conf config file to be in the clamav\bin directory. That should solve the restart errors. Best regards Nico

Thanks Nico, but I don't have a clamav\bin directory, all the files are in clamav.

Going from Lukas' documentation for Clamself mode, and what has worked in the past, the .exe and the .conf must be in the same directory, and that must be specified in the clamdir setting.

I am just about to do an upgrade so I will change the configuration and see what happens.

&lt;P&gt;Thanks Nico, but I don&#039;t have a clamav\bin directory, all the files are in clamav.&lt;/P&gt; &lt;P&gt;Going from&amp;nbsp;Lukas&#039; documentation for Clamself mode, and what has worked in the past,&amp;nbsp;the .exe and the .conf must be in the same directory, and that&amp;nbsp;must be specified in the clamdir setting.&lt;/P&gt; &lt;P&gt;I am just about to do an upgrade so I will change the configuration and see what happens.&lt;/P&gt;

[quote user="tBB"]As Rolf Lindby already mentioned, the ClamSelf mode requires the clamd.conf config file to be in the clamav\bin directory. That should solve the restart errors.
[/quote]

Of course I had installed the .conf files in the \bin directory - otherwise the clamself mode did not work at all.
If my problem concerns only some but not all Mercury users, it may depend on the version of ClamAV and/or the Windows version on the Mercury machine. I use ClamAV 0.91.1 from hideout.ath.cx, running together with Mercury/32 v4.51 on a Windows Server 2003, ClamWall v 1.1.4.78.

By the way, I had reported another problem some postings ago in this thread:

[quote user="Thomas Richter"]If you enable reporting ("Report bans back to the message sender") ther is a problem in resolving the senders address.

May be the senders from: is "Jim Tonic" <jimtonic@bartenders.com> and the mail has no virus but a banned attachment (.pif, .lnl, .exe). One reporting mail is correctly sent to jimtonic@bartenders.com but ClamWall will send the same mail to the address Jim Tonic, what results in an error message to the postmaster "User Jim Tonic not known at this site."
[/quote]

Is this also a problem that occurs only in a few installations or are there other users with the same problem - or a solution for this problem ?

Regards
Thomas
 

&lt;p&gt;[quote user=&quot;tBB&quot;]As Rolf Lindby already mentioned, the ClamSelf mode requires the clamd.conf config file to be in the clamav\bin directory. That should solve the restart errors. [/quote]&lt;/p&gt;&lt;p&gt;Of course I had installed the .conf files in the \bin directory - otherwise the clamself mode did not work at all. If my problem concerns only some but not all Mercury users, it may depend on the version of ClamAV and/or the Windows version on the Mercury machine. I use ClamAV 0.91.1 from hideout.ath.cx, running together with Mercury/32 v4.51 on a Windows Server 2003, ClamWall v 1.1.4.78.&lt;/p&gt;&lt;p&gt;By the way, I had reported another problem some postings ago in this thread:&lt;/p&gt;&lt;p&gt;[quote user=&quot;Thomas Richter&quot;]If you enable reporting (&quot;Report bans back to the message sender&quot;) ther is a problem in resolving the senders address. &lt;/p&gt;&lt;p&gt;May be the senders from: is &lt;b&gt;&quot;Jim Tonic&quot; &amp;lt;jimtonic@bartenders.com&amp;gt; &lt;/b&gt;and the mail has no virus but a banned attachment (.pif, .lnl, .exe). One reporting mail is correctly sent to &lt;b&gt;jimtonic@bartenders.com &lt;/b&gt;but ClamWall will send the same mail to the address &lt;b&gt;Jim Tonic&lt;/b&gt;, what results in an error message to the postmaster &quot;User Jim Tonic not known at this site.&quot; [/quote]&lt;/p&gt;&lt;p&gt;Is this also a problem that occurs only in a few installations or are there other users with the same problem - or a solution for this problem ? Regards Thomas &amp;nbsp;&lt;/p&gt;

[quote user="PaulW"]

Thanks Nico, but I don't have a clamav\bin directory, all the files are in clamav.

Going from Lukas' documentation for Clamself mode, and what has worked in the past, the .exe and the .conf must be in the same directory, and that must be specified in the clamdir setting.

[/quote]

Ah, I see. You're right, the Clamself mode shouldn't require a full installation. The SVN package you're using should do as well.

[quote user=" Thomas Richter"]

Of course I had installed the .conf files in the \bin directory - otherwise the clamself mode did not work at all.
If my problem concerns only some but not all Mercury users, it may depend on the version of ClamAV and/or the Windows version on the Mercury machine. I use ClamAV 0.91.1 from hideout.ath.cx, running together with Mercury/32 v4.51 on a Windows Server 2003, ClamWall v 1.1.4.78.

[/quote]

I've just talked it over with Lukas over IM. He suggests that you should check if you are using full paths in the config files because the preconfigured clamd.conf, which is available at Lukas's page uses relative paths, which requires a specially compiled ClamAv version (with the disadvantage that it /only/ runs in conjunction with ClamWall then). Lukas stopped compiling this version some time ago and uses the version from hideout.ath.cx since then (which is, btw, my distribution) :)

The next ClamWall version will have a additional configuration option for the location of the config file.

Best regards

Nico
[quote user=&quot;PaulW&quot;] &lt;P&gt;Thanks Nico, but I don&#039;t have a clamav\bin directory, all the files are in clamav. Going from&nbsp;Lukas&#039; documentation for Clamself mode, and what has worked in the past,&nbsp;the .exe and the .conf must be in the same directory, and that&nbsp;must be specified in the clamdir setting.&lt;/P&gt;[/quote] Ah, I see.&nbsp;You&#039;re&nbsp;right,&nbsp;the&nbsp;Clamself&nbsp;mode&nbsp;shouldn&#039;t&nbsp;require&nbsp;a&nbsp;full&nbsp;installation.&nbsp;The&nbsp;SVN&nbsp;package&nbsp;you&#039;re&nbsp;using&nbsp;should&nbsp;do as well. [quote user=&quot; Thomas Richter&quot;] Of course I had installed the .conf files in the \bin directory - otherwise the clamself mode did not work at all. If my problem concerns only some but not all Mercury users, it may depend on the version of ClamAV and/or the Windows version on the Mercury machine. I use ClamAV 0.91.1 from hideout.ath.cx, running together with Mercury/32 v4.51 on a Windows Server 2003, ClamWall v 1.1.4.78. [/quote] I&#039;ve just talked it over with Lukas over IM. He suggests that you should check if you are using full paths in the config files because the preconfigured clamd.conf, which is available at Lukas&#039;s page uses relative paths, which requires a specially compiled ClamAv version (with the disadvantage that it /only/ runs in conjunction with ClamWall then). Lukas stopped compiling this version some time ago&nbsp;and&nbsp;uses&nbsp;the version from hideout.ath.cx since&nbsp;then&nbsp;(which&nbsp;is,&nbsp;btw,&nbsp;my&nbsp;distribution)&nbsp;:) The next ClamWall version will have a additional configuration option&nbsp;for&nbsp;the&nbsp;location&nbsp;of&nbsp;the&nbsp;config&nbsp;file. Best regards Nico

I had the same problem and found it was the way I was installing ClamAV and starting it.  Install ClamAV [tBB] using all of it's defaults.  I then created a batch file and placed it in the ClamAV directory to start both Clamd and Freshclam. 

Below are the lines in the batch file.

Rem *** Starts Clamd as a service

c:\clamav\bin\clamd.exe

Rem *** Starts FreshClam as a service

c:\clamav\bin\freshclam.exe –d

I then created a short cut in the Startup directory to launch it on boot up.

If you want me to send you my work instructions, please contact me off line.

 

&lt;P&gt;I had the same problem and found it was the way I was installing ClamAV and starting it.&amp;nbsp; Install ClamAV [tBB] using all of it&#039;s defaults.&amp;nbsp; I then created a batch file and placed it in the ClamAV directory to start both Clamd and Freshclam.&amp;nbsp; &lt;/P&gt; &lt;P&gt;Below are the lines in the batch file.&lt;/P&gt; &lt;P class=MsoNormal style=&quot;MARGIN: 0in 0in 0pt 1in&quot;&gt;&lt;FONT face=&quot;Times New Roman&quot; size=3&gt;Rem *** Starts Clamd as a service&lt;/FONT&gt;&lt;/P&gt; &lt;P class=MsoNormal style=&quot;MARGIN: 0in 0in 0pt 1in&quot;&gt;&lt;FONT face=&quot;Times New Roman&quot; size=3&gt;c:\clamav\bin\clamd.exe&lt;/FONT&gt;&lt;/P&gt; &lt;P class=MsoNormal style=&quot;MARGIN: 0in 0in 0pt 1in&quot;&gt;&lt;FONT face=&quot;Times New Roman&quot; size=3&gt;Rem *** Starts FreshClam as a service&lt;/FONT&gt;&lt;/P&gt; &lt;P class=MsoNormal style=&quot;MARGIN: 0in 0in 0pt 1in&quot;&gt;&lt;FONT face=&quot;Times New Roman&quot; size=3&gt;c:\clamav\bin\freshclam.exe &ndash;d&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;I then created a short cut in the Startup directory to launch it on boot up.&lt;/P&gt; &lt;P&gt;If you want me to send you my work instructions, please contact me off line.&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt;

[quote user="tBB"]I've just talked it over with Lukas over IM. He suggests that you should check if you are using full paths in the config files because the preconfigured clamd.conf, which is available at Lukas's page uses relative paths, which requires a specially compiled ClamAv version (with the disadvantage that it /only/ runs in conjunction with ClamWall then). Lukas stopped compiling this version some time ago and uses the version from hideout.ath.cx since then (which is, btw, my distribution) :)
[/quote]

I didn't use Lukas' clamd.conf. At first I have installed your distribution ( hideout.ath.cx ) to the path - C:\programs\clamav and have copied your .conf files from \etc into \bin. In ClamAV I selected C.\programs\clamav\bin as ClamAV location. After starting mercury the ClamWall log said, that ClamAV could not be started. The reason was, that the paths to the database and log files are wrong now. Thats why I have remoded and reinstalled ClamAV to the original directory C:\clamav, copied the .conf files back into \bin and restarted the server. And now the behaviour reported at the beginning of this thread started - multiple instances of clamd and freshclam.

I also tried to chance the paths in the .conf files but it changed nothing. The only way was starting clamd and freshclam -d before mercury and configuring ClamWall to "External ClamAV daemon".

[quote user="tBB"]The next ClamWall version will have a additional configuration option for the location of the config file.
[/quote]
That would be a very good idea.

Nico, if you have contact to Lukas - can you ask him for my second problem - the reporting back to the message sender ?

Thanks
Thomas
 

&lt;p&gt;[quote user=&quot;tBB&quot;]I&#039;ve just talked it over with Lukas over IM. He suggests that you should check if you are using full paths in the config files because the preconfigured clamd.conf, which is available at Lukas&#039;s page uses relative paths, which requires a specially compiled ClamAv version (with the disadvantage that it /only/ runs in conjunction with ClamWall then). Lukas stopped compiling this version some time ago and uses the version from hideout.ath.cx since then (which is, btw, my distribution) :) [/quote]&lt;/p&gt;&lt;p&gt;I didn&#039;t use Lukas&#039; clamd.conf. At first I have installed your distribution ( hideout.ath.cx ) to the path - C:\programs\clamav and have copied your .conf files from \etc into \bin. In ClamAV I selected C.\programs\clamav\bin as ClamAV location. After starting mercury the ClamWall log said, that ClamAV could not be started. The reason was, that the paths to the database and log files are wrong now. Thats why I have remoded and reinstalled ClamAV to the original directory C:\clamav, copied the .conf files back into \bin and restarted the server. And now the behaviour reported at the beginning of this thread started - multiple instances of clamd and freshclam.&lt;/p&gt;&lt;p&gt;I also tried to chance the paths in the .conf files but it changed nothing. The only way was starting clamd and freshclam -d before mercury and configuring ClamWall to &quot;External ClamAV daemon&quot;. &lt;/p&gt;&lt;p&gt;[quote user=&quot;tBB&quot;]The next ClamWall version will have a additional configuration option for the location of the config file. [/quote] That would be a very good idea.&lt;/p&gt;&lt;p&gt;Nico, if you have contact to Lukas - can you ask him for my second problem - the reporting back to the message sender ?&lt;/p&gt;&lt;p&gt;Thanks Thomas &amp;nbsp;&lt;/p&gt;

[quote user="Thomas Richter"]

I didn't use Lukas' clamd.conf. At first I have installed your distribution ( hideout.ath.cx ) to the path - C:\programs\clamav and have copied your .conf files from \etc into \bin. In ClamAV I selected C.\programs\clamav\bin as ClamAV location. After starting mercury the ClamWall log said, that ClamAV could not be started. The reason was, that the paths to the database and log files are wrong now. Thats why I have remoded and reinstalled ClamAV to the original directory C:\clamav, copied the .conf files back into \bin and restarted the server. And now the behaviour reported at the beginning of this thread started - multiple instances of clamd and freshclam.
[/quote]

I'll contact you off-list (of course I'll post the solution here..in case we find one) :)

[quote user="Thomas Richter"]

Nico, if you have contact to Lukas - can you ask him for my second problem - the reporting back to the message sender ?

[/quote]

OK I'll do. He's currently having a extremely busy time at work, hence no replys from him here.

Best regards

Nico
[quote user=&quot;Thomas Richter&quot;]&lt;P&gt;I didn&#039;t use Lukas&#039; clamd.conf. At first I have installed your distribution ( hideout.ath.cx ) to the path - C:\programs\clamav and have copied your .conf files from \etc into \bin. In ClamAV I selected C.\programs\clamav\bin as ClamAV location. After starting mercury the ClamWall log said, that ClamAV could not be started. The reason was, that the paths to the database and log files are wrong now. Thats why I have remoded and reinstalled ClamAV to the original directory C:\clamav, copied the .conf files back into \bin and restarted the server. And now the behaviour reported at the beginning of this thread started - multiple instances of clamd and freshclam. [/quote] I&#039;ll contact you off-list (of course I&#039;ll post the solution here..in case we find one) :) [quote user=&quot;Thomas Richter&quot;] &lt;/P&gt;&lt;P&gt;Nico, if you have contact to Lukas - can you ask him for my second problem - the reporting back to the message sender ?&lt;/P&gt;[/quote] OK I&#039;ll do.&nbsp;He&#039;s currently having a extremely busy time at work, hence no replys from him here. Best regards Nico

[quote user="PaulW"]I am just about to do an upgrade so I will change the configuration and see what happens.[/quote]

Well, the upgrade seems to have sorted the problem for me.

Whether it was the newer version of clamav, or the stopping and restarting of clamav, I can't tell.

 

&lt;P&gt;[quote user=&quot;PaulW&quot;]I am just about to do an upgrade so I will change the configuration and see what happens.[/quote]&lt;/P&gt; &lt;P&gt;Well, the upgrade seems to have sorted the problem for me.&lt;/P&gt; &lt;P&gt;Whether it was the newer version of clamav, or the stopping and restarting of clamav, I can&#039;t tell.&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt;

We also had ClamAV and FreshClam trying to start for each incoming message, but I think that started already in April so it wasn't related to M/32 4.51. There wasn't multiple processes, though, in fact ClamAV probably never started at all. Nico's new version solved that for us as well, but as I mentioned in an earlier post we need 2 copies of the conf files to get it working, one in the bin directory where the program files are, and one on the C: drive in the location that's hardcoded into the program.

/Rolf
 

&lt;p&gt;We also had ClamAV and FreshClam trying to start for each incoming message, but I think that started already in April so it wasn&#039;t related to M/32 4.51. There wasn&#039;t multiple processes, though, in fact ClamAV probably never started at all. Nico&#039;s new version solved that for us as well, but as I mentioned in an earlier post we need 2 copies of the conf files to get it working, one in the bin directory where the program files are, and one on the C: drive in the location that&#039;s hardcoded into the program.&lt;/p&gt;&lt;p&gt;/Rolf &amp;nbsp;&lt;/p&gt;

That's strange - using tBB's versions I have never ever used the default structure.

I'll try and find time to play about a bit to see if I can recreate a problem.

&lt;P&gt;That&#039;s strange - using tBB&#039;s versions I have never ever used the default&amp;nbsp;structure.&lt;/P&gt; &lt;P&gt;I&#039;ll try and find time to play about a bit to see if I can recreate a problem.&lt;/P&gt;

After seeing all the problems concerning the selfclam mode I asked myself why it is necessary that ClamWall starts and stops ClamAV ?

For me myself it seems to be the better way, to start clamd and fresclam (with the -d option) from an batch or from the Startup folder. Then the only thing that must be configurated is the port on which ClamAV and ClamWall will communicate.

The advantage of this method would be, that everybody can use his preferred version of ClamAV and that Lukas Gebauer need not to write a configuration interface for ClamAV. And after all the postings here I assume, that the start of multiple instances of clamd and freshclam depends on the used operating system and/or Mercury version and/or timing problems.

Thomas
 

&lt;p&gt;After seeing all the problems concerning the selfclam mode I asked myself why it is necessary that ClamWall starts and stops ClamAV ?&lt;/p&gt;&lt;p&gt;For me myself it seems to be the better way, to start clamd and fresclam (with the -d option) from an batch or from the Startup folder. Then the only thing that must be configurated is the port on which ClamAV and ClamWall will communicate.&lt;/p&gt;&lt;p&gt;The advantage of this method would be, that everybody can use his preferred version of ClamAV and that Lukas Gebauer need not to write a configuration interface for ClamAV. And after all the postings here I assume, that the start of multiple instances of clamd and freshclam depends on the used operating system and/or Mercury version and/or timing problems.&lt;/p&gt;&lt;p&gt;Thomas &amp;nbsp;&lt;/p&gt;

As for the multiple notifications to non existing users, that turned out to be a bug (or rather a misunderstanding between ClamWall and the daemon API). It will be fixed in the next version which will probably come in a week or two.

Best regards

Nico

As for the multiple notifications to non existing users, that turned out to be a bug (or rather a misunderstanding between ClamWall and the daemon API).&nbsp;It&nbsp;will&nbsp;be&nbsp;fixed&nbsp;in&nbsp;the&nbsp;next&nbsp;version&nbsp;which&nbsp;will&nbsp;probably&nbsp;come&nbsp;in a week or two. Best regards Nico
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft