Martin Blapp [EMAIL PROTECTED] writes:
Hi,
I just fixed those issues with the port.
Thanks for reporting !
So we can safely use libpthread.so again? No need to use libmap.conf?
--
One cannot sell the earth upon which the people walk
Tacunka
MacGregor; clamav-devel@lists.clamav.net;
freebsd-stable@freebsd.org
Subject: Re: Clamav-90_2 Lockup with freebsd 6.2
Hi,
I just fixed those issues with the port.
Thanks for reporting !
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED
Hi,
I am not sure why. But my dual xeon with libthr on clamav-90.1 still gives
very high cpu usage.
It's the same case here. What happens if you limit kern.smp.maxcpus
to 1 ? Does it still use the same amount cpu time ? What happens if
you link clamd against libc_r ?
--
Martin
Hi,
I just fixed those issues with the port.
Thanks for reporting !
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93
[snip patch]
Does this patch make the libmap.conf hack unneeded?
I frist thought so, but no, the more threads are running concurrently
the slower libpthreads behaves, as it gets more lock contention. Until
this is addressed somehow, use libthr.so
FWIW, we have several machines running with
At 01:52 PM 3/15/2007, Kevin Way wrote:
FWIW, we have several machines running with the libmap.conf hack.
clamav no longer locks up, but has instead taken to occasionally
dying altogether.
Hi,
I think there are other bugs in the current clamd, the main one that
we run into is when it tries
Mike Tancsa unleashed the infinite monkeys on 15/03/2007 19:58 producing:
At 01:52 PM 3/15/2007, Kevin Way wrote:
FWIW, we have several machines running with the libmap.conf hack.
clamav no longer locks up, but has instead taken to occasionally dying
altogether.
Hi,
I think there are other
On Thu, Mar 15, 2007 at 08:28:10PM +, Rob MacGregor wrote:
FWIW, we have several machines running with the libmap.conf hack.
clamav no longer locks up, but has instead taken to occasionally dying
altogether.
Hi,
I think there are other bugs in the current clamd, the main one that
Hi,
[snip patch]
Does this patch make the libmap.conf hack unneeded?
I frist thought so, but no, the more threads are running concurrently
the slower libpthreads behaves, as it gets more lock contention. Until
this is addressed somehow, use libthr.so
--
Martin
On Sat, 10 Mar 2007, Mike Jakubik wrote:
Martin Blapp wrote:
Clamd with libpthread.so is still broken. Please use libthr.so. I'm
currently
investigating why libpthreads.so has problems with clamd, and it looks to
me
like a library bug.
This may be related to a problem i had with Mysql on a
Hi,
Don't use it, it's broken.
-trog
Nope, it looks like a race in cli_scanmail() which deadlocks somewhere
with libpthread.so. This workaround fixes the problem for me. I'm still
investigating where the real cause for this problem is.
--- libclamav/scanners.cTue Feb 13 02:06:28
And even more narrowed down ...
--- libclamav/mbox.c.orig Tue Feb 13 14:06:57 2007
+++ libclamav/mbox.cSat Mar 10 14:09:09 2007
@@ -413,6 +413,7 @@
#ifdef CL_THREAD_SAFE
static pthread_mutex_t tables_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t body_mutex =
Martin Blapp wrote:
Clamd with libpthread.so is still broken. Please use libthr.so. I'm
currently
investigating why libpthreads.so has problems with clamd, and it looks
to me
like a library bug.
This may be related to a problem i had with Mysql on a large server
recently. Mysql threads
Renato Botelho [EMAIL PROTECTED] writes:
I found the problem, a bad REINPLACE_CMD was changing wrong var on configure
scripts, don't respecting PTHREAD_LIBS.
It's fixed now on 0.90_3.
No, It's not. Today I added a new server with fresh clamav-0.90_3
package. Sockstat again started to jump to
Hi,
No, It's not. Today I added a new server with fresh clamav-0.90_3
package. Sockstat again started to jump to the sky.
Clamd with libpthread.so is still broken. Please use libthr.so. I'm currently
investigating why libpthreads.so has problems with clamd, and it looks to me
like a library
Subject: Re: Clamav-90_2 Lockup with freebsd 6.2
Hi,
No, It's not. Today I added a new server with fresh clamav-0.90_3
package. Sockstat again started to jump to the sky.
Clamd with libpthread.so is still broken. Please use libthr.so. I'm
currently
investigating why libpthreads.so has problems
Shikoff
Subject: Re: Clamav-90_2 Lockup with freebsd 6.2
Hi,
No, It's not. Today I added a new server with fresh clamav-0.90_3
package. Sockstat again started to jump to the sky.
Clamd with libpthread.so is still broken. Please use libthr.so. I'm
currently
investigating why libpthreads.so
Mike Tancsa wrote:
Create the file /etc/libmap.conf with the contents
[clamd]
libthr.so.2 libthr.so.2
I don't know why that error keeps cropping up, but it should be noted
that this isn't necessary, or desirable.
Doug
--
This .signature sanitized for your protection
At 04:43 PM 3/8/2007, Doug Barton wrote:
Mike Tancsa wrote:
Create the file /etc/libmap.conf with the contents
[clamd]
libthr.so.2 libthr.so.2
I don't know why that error keeps cropping up, but it should be
noted that this isn't necessary, or desirable.
Thanks,
It
On Tue, Mar 06, 2007 at 03:58:33PM -0500, Mike Tancsa wrote:
At 10:55 AM 3/1/2007, Renato Botelho wrote:
FYI: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=307#c8
I found the problem, a bad REINPLACE_CMD was changing wrong var on
configure
scripts, don't respecting PTHREAD_LIBS.
On 06/03/07, Mike Tancsa [EMAIL PROTECTED] wrote:
At 10:55 AM 3/1/2007, Renato Botelho wrote:
FYI: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=307#c8
I found the problem, a bad REINPLACE_CMD was changing wrong var on configure
scripts, don't respecting PTHREAD_LIBS.
It's fixed now on
What configuration in exim is needed to make it use tcp instead of sockets?
av_scanner = clamd:127.0.0.1 3310
instead of
av_scanner = clamd:/var/run/clamav/clamd
and then in clamd.conf, comment out 'LocalSocket' and uncomment the
'TCPSocket' and 'TCPAddr' settings so it looks
On 07/03/07, Pete French [EMAIL PROTECTED] wrote:
What configuration in exim is needed to make it use tcp instead of sockets?
av_scanner = clamd:127.0.0.1 3310
instead of
av_scanner = clamd:/var/run/clamav/clamd
and then in clamd.conf, comment out 'LocalSocket' and uncomment
On Thu, Mar 01, 2007 at 03:43:26PM +0200, Alexander Shikoff wrote:
Hi All,
On Thu, Mar 01, 2007 at 08:32:55AM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Martin Blapp wrote:
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use
Hi,
On Fri, Mar 02, 2007 at 11:19:40AM -0300, Carlos Horowicz wrote:
Anybody tried this additionally in /etc/libmap.conf ?
[/usr/local/lib/libclamav.so.1]
libpthread.so.2 libthr.so.2
clamav-0.90_2 reduced CPU consumption for me on 6.2-Stable since I
added the two sections in
At 10:39 AM 3/6/2007, Oliver Brandmueller wrote:
last days with exim connecting to the local socket I have exim
now connecting to localhot:3310 by tcp. The difference is, that before
Perhaps this is why we were not seeing the high CPU usage post our
upgrade, as we have the milters on our
last days with exim connecting to the local socket I have exim
now connecting to localhot:3310 by tcp. The difference is, that before
clamd scanned all files in the directory given by exim. Effectively exim
was unpacking the whole MIME structure and placed all parts in the dir
Hello,
On Tue, Mar 06, 2007 at 04:45:37PM +, Pete French wrote:
last days with exim connecting to the local socket I have exim
now connecting to localhot:3310 by tcp. The difference is, that before
clamd scanned all files in the directory given by exim. Effectively exim
was
Had a similar behavior here, but with other MTA (qmail, clamdscan
getting used from simscan).
After raising MaxThreads from 10 (default) to 40 CPU usage got back to
its normal consuming level.
No idea if this info can help, but that was my recent experience.
:[EMAIL PROTECTED] Behalf Of Renato Botelho
Sent: Friday, 2 March 2007 2:56 AM
To: Alexander Shikoff
Cc: Marko Lerota; Chris; freebsd-stable@FreeBSD.org; Daniel Eischen;
Martin Blapp; Anton Karpov
Subject: Re: Clamav-90_2 Lockup with freebsd 6.2
On Thu, Mar 01, 2007 at 03:43:26PM +0200, Alexander
At 10:55 AM 3/1/2007, Renato Botelho wrote:
FYI: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=307#c8
I found the problem, a bad REINPLACE_CMD was changing wrong var on configure
scripts, don't respecting PTHREAD_LIBS.
It's fixed now on 0.90_3.
Any chance to update the port to use
After further analyzing I think that pthread_cond_timedwait() in
libpthread.so.2 has some issues.
While the default clamd worker timeout of 30 seconds is reached with
libc_r.so.6 and libthr.so.2 and pthread_cond_timedwait() returns ETIMEDOUT
there, libpthread.so doesn't get any ETIMEDOUT
On 01/03/07, Renato Botelho [EMAIL PROTECTED] wrote:
On Thu, Mar 01, 2007 at 02:04:18PM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Alexander Shikoff wrote:
Hi All,
On Thu, Mar 01, 2007 at 08:32:55AM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Martin Blapp wrote:
Hi,
Hi all,
After adding some debug stuff to clamd running with freebsd
libpthread.so I found that:
looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l'
is always staying at 6 threads, but the number of threadpool-thr_alive is
going higher and higher. So
Hi,
looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l'
is always staying at 6 threads, but the number of threadpool-thr_alive is
going higher and higher. So threadpool-thr_alive isn't decreased and
is completly incorrect.
After setting IdleTimeout very low to 5
On Sun, 4 Mar 2007, Martin Blapp wrote:
Hi all,
After adding some debug stuff to clamd running with freebsd
libpthread.so I found that:
looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l'
is always staying at 6 threads, but the number of threadpool-thr_alive is
Hi,
Make sure clamd is checking the return value of pthread_create()
for errors. You can also set LIBPTHREAD_PROCESS_SCOPE=yes or
LIBPTHREAD_SYSTEM_SCOPE=yes in your environment to force process
scope or system scope threads (libpthread only) for clamd.
Yes, it does check the return value.
Hi,
[/usr/local/sbin/clamd]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
libc_r.so.6 libpthread.so.2
Correct, just delete the last line. I forgot to delete
the only entry.
The right side of that last line should probably refer to libthr.so.2.
AFAICS,
Hi,
Anybody tried this additionally in /etc/libmap.conf ?
[/usr/local/lib/libclamav.so.1]
libpthread.so.2 libthr.so.2
clamav-0.90_2 reduced CPU consumption for me on 6.2-Stable since I added the
two sections in libmap.conf
-Carlos
2007/3/1, Doug Barton [EMAIL PROTECTED]:
Martin
Anybody tested today released clamav-0.90.1 ??
On 3/2/07, Carlos Horowicz [EMAIL PROTECTED] wrote:
Hi,
Anybody tried this additionally in /etc/libmap.conf ?
[/usr/local/lib/libclamav.so.1]
libpthread.so.2 libthr.so.2
clamav-0.90_2 reduced CPU consumption for me on 6.2-Stable since I
On 28/02/07, Marko Lerota [EMAIL PROTECTED] wrote:
Martin Blapp [EMAIL PROTECTED] writes:
Even with libthr the CPU usage is still far too high ...
I'm currently looking at the code.
Take a look at this post. I also have CPU usage problems and simscan
installed.
Chris [EMAIL PROTECTED] writes:
I dont use simscan but use clamav for scanning emails passed from
exim. I noticed that cpu usage went through the roof and there was
dozens of clamd in sockstat. On a dual xeon it did cause some smtp
lag but on weaker specs it caused the smtp to completely
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU hungry, but
works better).
/etc/libmap.conf
[/usr/local/sbin/clamd]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
libc_r.so.6
On Thu, 1 Mar 2007, Martin Blapp wrote:
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU hungry, but
works better).
I don't think it is a problem with libpthread.
--
DE
Hi All,
On Thu, Mar 01, 2007 at 08:32:55AM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Martin Blapp wrote:
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU hungry, but
works better).
I don't think it
Martin Blapp wrote:
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU hungry, but
works better).
/etc/libmap.conf
[/usr/local/sbin/clamd]
libpthread.so.2 libthr.so.2
libpthread.so
On Thu, 1 Mar 2007, Alexander Shikoff wrote:
Hi All,
On Thu, Mar 01, 2007 at 08:32:55AM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Martin Blapp wrote:
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU
On 2/26/07, Dimuthu Parussalla [EMAIL PROTECTED] wrote:
Clamav-90_2 Lockup with freebsd 6.2
Still under load clamav_90_2 locks up with high cpu usage. Had to downgrade
the port to 88.7_1 to get the server going. Sockstat shows lots of open
sockets from clamd.
I've been seeing excessive CPU
Martin Blapp [EMAIL PROTECTED] writes:
Even with libthr the CPU usage is still far too high ...
I'm currently looking at the code.
Take a look at this post. I also have CPU usage problems and simscan
installed.
http://www.mail-archive.com/toaster@shupp.org/msg04119.html
Re: [toaster]
Hi,
Change the threading lib. It fixed it for us.
% cat /etc/libmap.conf
[clamd]
libc_r.so.5 libthr.so.2
libc_r.so.6 libthr.so.2
libthr.so.2 libthr.so.2
libpthread.so.1 libthr.so.2
libpthread.so.2 libthr.so.2
Even with libthr the CPU
@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Blapp
Sent: Tuesday, February 27, 2007 11:37 AM
To: Sergey N. Voronkov
Cc: freebsd-stable@freebsd.org
Subject: Re: Clamav-90_2 Lockup
Was this indeed compiled with pthread or with lpthread?
I had this issue on a 4.11-RELEASE machine very recently. As it does
not have lpthread, it would fail to compile against this.
Martin Blapp wrote:
Hi,
Change the threading lib. It fixed it for us.
% cat /etc/libmap.conf
[clamd]
At 12:36 PM 2/27/2007, Martin Blapp wrote:
Hi,
Change the threading lib. It fixed it for us.
% cat /etc/libmap.conf
[clamd]
libc_r.so.5 libthr.so.2
libc_r.so.6 libthr.so.2
libthr.so.2 libthr.so.2
libpthread.so.1 libthr.so.2
libpthread.so.2
PROTECTED] Behalf Of Martin Blapp
Sent: Wednesday, 28 February 2007 4:37 AM
To: Sergey N. Voronkov
Cc: freebsd-stable@freebsd.org
Subject: Re: Clamav-90_2 Lockup with freebsd 6.2
Hi,
Change the threading lib. It fixed it for us.
% cat /etc/libmap.conf
[clamd]
libc_r.so.5
On Wed, 28 Feb 2007, Dimuthu Parussalla wrote:
Hi,
I can confirm the same situation. My dual xeon x236 server runs very high
cpu utilisation with clamav. Also tried with maxthreads to 1. Result is the
same but frequency of locked process seems to be reduced.
I think clamav has a bug
At 07:12 PM 2/26/2007, Dimuthu Parussalla wrote:
Clamav-90_2 Lockup with freebsd 6.2
Still under load clamav_90_2 locks up with high cpu usage. Had to downgrade
the port to 88.7_1 to get the server going. Sockstat shows lots of open
sockets from clamd.
I am using simscan+Qmail+Clamav.
Any
On Mon, Feb 26, 2007 at 10:05:35PM -0500, Mike Tancsa wrote:
At 07:12 PM 2/26/2007, Dimuthu Parussalla wrote:
Clamav-90_2 Lockup with freebsd 6.2
Still under load clamav_90_2 locks up with high cpu usage. Had to downgrade
the port to 88.7_1 to get the server going. Sockstat shows lots of
57 matches
Mail list logo
