Hello Nigel,
Tuesday, September 14, 2004, 10:48:44 AM, you wrote:
I want to use this option for two servers runing clamd.
What commandline for clamav-milter should be?
NH Here's my command line:
NH /usr/local/sbin/clamav-milter --max-children=2 --debug
NH --dont-wait --timeout=0
NH
* Fajar A. Nugraha [EMAIL PROTECTED]:
Which brings my earlier suggestion. Is there any way to put a
built-in memory limiter (not external program like softlimit) to
clamd?
Why add code to clamd when a good unix-like solution already exists?
--
Ralf Hildebrandt (i.A. des IT-Zentrum)
Fajar A. Nugraha wrote:
D Walsh wrote:
I sat down in front of a Solaris 9 system, installed clamav as
instructed and yes indeed there appears to be a problem with the
implementation of free(), in 30 mins of sending e-mail from the EICAR
test site memory did climb to 2.87gb and did not clear
On Sep 15, 2004, at 01:48, Fajar A. Nugraha wrote:
D Walsh wrote:
I sat down in front of a Solaris 9 system, installed clamav as
instructed and yes indeed there appears to be a problem with the
implementation of free(), in 30 mins of sending e-mail from the EICAR
test site memory did climb
Ralf Hildebrandt wrote:
* Fajar A. Nugraha [EMAIL PROTECTED]:
Which brings my earlier suggestion. Is there any way to put a
built-in memory limiter (not external program like softlimit) to
clamd?
Why add code to clamd when a good unix-like solution already exists?
Because softlimit is a
* Fajar A. Nugraha [EMAIL PROTECTED]:
Because softlimit is a hack.
It is not a hack. It is common pratice to run programs using least
privilege and with limited resource to prevent runaway conditions.
Because current clamd implementation is not to die on
memory allocation error, but sleep.
* On 2004.09.15, in [EMAIL PROTECTED],
* D Walsh [EMAIL PROTECTED] wrote:
I sat down in front of a Solaris 9 system, installed clamav as
instructed and yes indeed there appears to be a problem with the
implementation of free(), in 30 mins of sending e-mail from the EICAR
test
Hi,
I just wonder why 'clamscan --mbox' says OK whenever there is a 'X-Virus-Flag:
Yes' mail header line (a virus a definitely included). If I remove this
header line from the mail, the same command reports the virus correctly.
Wouldn't it be good advice for virus programmers to include
2) *IMPORTANT QUESTION* is there an option I can setup so if a user sends
an attachment that Clam will look at and see a potential virus (based upon
my attachment rules) and email the user back telling them that the email
will not be sent?
clamav-milter has that option (but you're using
On Wednesday 15 Sep 2004 07:23, Max Chernogor wrote:
I want to use this option for two servers runing clamd.
What commandline for clamav-milter should be?
NH Here's my command line:
NH /usr/local/sbin/clamav-milter --max-children=2 --debug
NH --dont-wait --timeout=0
NH
David Champion wrote:
[snip]
All this is just to throw in with that camp that says these are no
indications of memory leaks. Now back to your regularly-scheduled virus
discussion.
Your comment has been the most enlightning so far on memory allocation :)
Okay, now suppose that clamd works in a
On Wed, Sep 15, 2004 at 09:58:41AM +0200, Ralf Hildebrandt wrote:
Because current clamd implementation is not to die on
memory allocation error, but sleep.
It doesn't die, it's being killed by the kernel.
No - clamd does a malloc and that fails. Then instead of dying (which would
be the
On Wed, 15 Sep 2004 10:12:01 +0200, Tim Ruehsen [EMAIL PROTECTED] wrote:
Hi,
I just wonder why 'clamscan --mbox' says OK whenever there is a 'X-Virus-Flag:
Yes' mail header line (a virus a definitely included). If I remove this
header line from the mail, the same command reports the virus
On Wed, 2004-09-15 at 10:16, Fajar A. Nugraha wrote:
Do you have any suggestion as to how to get back the free()d memory?
Will (borrowing Apache's way) using a prefork-kind of daemon, with
limited lifetime
for each child, be better (in sense of memory management) than the current
thread
* Jason Haar [EMAIL PROTECTED]:
On Wed, Sep 15, 2004 at 09:58:41AM +0200, Ralf Hildebrandt wrote:
Because current clamd implementation is not to die on
memory allocation error, but sleep.
It doesn't die, it's being killed by the kernel.
No - clamd does a malloc and that fails. Then
On Wed, 2004-09-15 at 12:27, Ralf Hildebrandt wrote:
* Jason Haar [EMAIL PROTECTED]:
On Wed, Sep 15, 2004 at 09:58:41AM +0200, Ralf Hildebrandt wrote:
Because current clamd implementation is not to die on
memory allocation error, but sleep.
It doesn't die, it's being killed by
On Tue, 14 Sep 2004 15:51:41 -0400, Bart Silverstrim
[EMAIL PROTECTED] wrote:
Hello,
I'm trying to integrate a clamav with a simple sitewide procmail recipe
to run clamscan-procfilter then take action if the headers contain the
virus tag (X-CLAMAV). The first part of the recipe in the script
On Tuesday 14 September 2004 22:05, Tomasz Kojm wrote:
On Tue, 14 Sep 2004 20:54:19 +0400
Dmitry Alexeyev [EMAIL PROTECTED] wrote:
BTW, is it possible to use unpacked database files with clamscan?
You can unpack databases with `sigtool --unpack-current main.cvd`
(the same for daily.cvd)
* Trog [EMAIL PROTECTED]:
Ok, THAT's bad - and should be fixed.
If it were true it would be. Please point me at some code in clamd that
does that.
That was not my claim, but the other person's.
--
Ralf Hildebrandt (i.A. des IT-Zentrum) [EMAIL PROTECTED]
Charite -
Quoting Nigel Horne [EMAIL PROTECTED]:
On Wednesday 15 Sep 2004 09:12, Tim Ruehsen wrote:
Hi,
I just wonder why 'clamscan --mbox' says OK whenever there is a
'X-Virus-Flag:
Yes' mail header line (a virus a definitely included). If I remove this
header line from the mail, the same command reports
On Wed, 2004-09-15 at 15:17, Ralf Hildebrandt wrote:
* Trog [EMAIL PROTECTED]:
Ok, THAT's bad - and should be fixed.
If it were true it would be. Please point me at some code in clamd that
does that.
That was not my claim, but the other person's.
I know, I believe I correctly
Do you have any suggestion as to how to get back the free()d memory?
Will (borrowing Apache's way) using a prefork-kind of daemon, with
limited lifetime
for each child, be better (in sense of memory management) than the current
thread implementation? Or perhaps limiting the lifetime of
Trog wrote:
Apache has been moving away from the prefork-kind of daemon towards
threads for a number of years.
Yes, but in case you didn't notice prefork is STILL the default MPM if
no specific one
is chosen. It's for compatibility purposes mostly, for modules that
are not thread-safe yet.
So
Ralf Hildebrandt wrote:
Fact: We've been running clamd for a week now, scanning 130.000 mails
per week.
With that amount you shouldn't have any problem.
Try 1157851 mail per day (that's yesterday's count on one of my MTAs).
Question: Why do I see 4 clamd processes?
Might be threads
* On 2004.09.15, in [EMAIL PROTECTED],
* Fajar A. Nugraha [EMAIL PROTECTED] wrote:
Do you have any suggestion as to how to get back the free()d memory?
Will (borrowing Apache's way) using a prefork-kind of daemon, with
limited lifetime
for each child, be better (in sense of memory
Fajar A. Nugraha writes:
Okay, now suppose that clamd works in a complicated way, so that
The effect is that you don't *always* get back what you free() when you
free(),
Do you have any suggestion as to how to get back the free()d memory?
Will (borrowing Apache's way) using a prefork-kind of
26 matches
Mail list logo
