Re: Strange trouble with clamd/greylist/mimedefang

2007-06-13 Thread BERTRAND Joël

BERTRAND Joël a écrit :

Clint Adams a écrit :

On Sat, Jun 09, 2007 at 08:46:53PM +0200, BERTRAND Joël wrote:
Right. For me, one think is very suspect. Milter-greylist nor 
clamd are not able to fork on kant.


What makes you think that they're unable to fork?


Because clamd uses multithread and multitask features.
When mimedefang send a mail to clamd socket, clamd forks itself to 
analyze this mail. On kant, clamd is not able to fork, or maybe is able 
to fork but cannot analyze any mail, and mimedefang aborts with a busy 
timeout. If I replace clamd by clamscan, mimedefang works (but alayze 
process take a very long time). When I try to replace clamscan by 
clamdscan that uses clamd, mimedefang hangs after a very short number of 
analyzes.


Maybe clamd implementation is broken with libc6 2.5.


The only significative difference for me is the libc release.

Root kant:[~]  dpkg-query -l libc6
...
ii  libc6  2.5-9  GNU C Library: Shared libraries

rayleigh:[~]   dpkg-query -l libc6
...
ii  libc6  2.3.6.ds1-13   GNU C Library: Shared libraries


2.5 gives you NPTL, which means that threaded programs can have real
threads instead of forking.



If you do a ps -eLf on a glibc2.5 system with numerous clamdscan
processes going, you will hopefully see multiple clamd lines
(same PID, different LWP number).

If you don't, maybe there's an issue with libpthread.


I see some clamd threads, but even with some threads, clamd cannot 
analyze inbound mails.


I have another question about threads. On a U80, with four 
UltraSparc processors, are two threads of one process limited to 
ressources given by one processor, or can they be shared on two 
processors (like regular process) ?


	Strange. Problem solved when I have rebooted my U80... I have seen a 
bind9 instability too that was solved by the same action...


Regards,

JKB


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Strange trouble with clamd/greylist/mimedefang

2007-06-10 Thread BERTRAND Joël

Clint Adams a écrit :

On Sat, Jun 09, 2007 at 08:46:53PM +0200, BERTRAND Joël wrote:
	Right. For me, one think is very suspect. Milter-greylist nor clamd 
	are not able to fork on kant.


What makes you think that they're unable to fork?


Because clamd uses multithread and multitask features.
When mimedefang send a mail to clamd socket, clamd forks itself to 
analyze this mail. On kant, clamd is not able to fork, or maybe is able 
to fork but cannot analyze any mail, and mimedefang aborts with a busy 
timeout. If I replace clamd by clamscan, mimedefang works (but alayze 
process take a very long time). When I try to replace clamscan by 
clamdscan that uses clamd, mimedefang hangs after a very short number of 
analyzes.


Maybe clamd implementation is broken with libc6 2.5.


The only significative difference for me is the libc release.

Root kant:[~]  dpkg-query -l libc6
...
ii  libc6  2.5-9  GNU C Library: Shared libraries

rayleigh:[~]   dpkg-query -l libc6
...
ii  libc6  2.3.6.ds1-13   GNU C Library: Shared libraries


2.5 gives you NPTL, which means that threaded programs can have real
threads instead of forking.



If you do a ps -eLf on a glibc2.5 system with numerous clamdscan
processes going, you will hopefully see multiple clamd lines
(same PID, different LWP number).

If you don't, maybe there's an issue with libpthread.


	I see some clamd threads, but even with some threads, clamd cannot 
analyze inbound mails.


	I have another question about threads. On a U80, with four UltraSparc 
processors, are two threads of one process limited to ressources given 
by one processor, or can they be shared on two processors (like regular 
process) ?


Regards,

JKB


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Strange trouble with clamd/greylist/mimedefang

2007-06-09 Thread BERTRAND Joël

Hello,

I use two UltraSparc workstations, the first one is an U80 named kant
([EMAIL PROTECTED]), the other one is an U60 named rayleigh ([EMAIL 
PROTECTED]). kant is
a MX1 mail server that runs on debian testing sendmail, milter-greylist,
mimedefang  with spamassassin and clamd. rayleigh is MX2.

On rayleigh, clamd and milter-greylist work fine. Some clamd process
and milter-greylist run at the same time, and this MX2 work.

rayleigh:[~]  ps auwx | grep milter
bertrand  3803  0.0  0.0   3520   976 pts/3S+   19:36   0:00 grep milter
root 23781  0.0  2.4  52144 24872 ?Ss   Jun08   0:00
/usr/local/bin/milter-greylist -P /var/run/greylist.pid -u root -p
/var/run/milter-greylist/greylist.sock
root 23782  0.0  2.4  52144 24872 ?SJun08   0:00
/usr/local/bin/milter-greylist -P /var/run/greylist.pid -u root -p
/var/run/milter-greylist/greylist.sock
root 23783  0.0  2.4  52144 24872 ?SJun08   0:51
/usr/local/bin/milter-greylist -P /var/run/greylist.pid -u root -p
/var/run/milter-greylist/greylist.sock
root 23784  0.0  2.4  52144 24872 ?SJun08   0:00
/usr/local/bin/milter-greylist -P /var/run/greylist.pid -u root -p
/var/run/milter-greylist/greylist.sock
root 23785  0.0  2.4  52144 24872 ?SJun08   0:00
/usr/local/bin/milter-greylist -P /var/run/greylist.pid -u root -p
/var/run/milter-greylist/greylist.sock
rayleigh:[~]  ps auwx | grep clamd
bertrand  3824  0.0  0.0   3520   976 pts/3S+   19:37   0:00 grep clamd
clamav   25331  1.0  7.6  86896 79376 ?Ss   15:19   2:39
/usr/sbin/clamd
clamav   26113  0.0  7.6  86896 79376 ?S15:34   0:00
/usr/sbin/clamd
rayleigh:[~] 

With exactly the _same_ configuration, only one milter-greylist and one
clamd process run on kant !

kant:[~]  ps auwx | grep milter
root  9973  0.0  0.1  69968  2600 ?Ssl  19:16   0:00
/usr/local/bin/milter-greylist -P /var/run/greylist.pid -u root -p
/var/run/milter-greylist/greylist.sock
bertrand 12436  0.0  0.0   3800  1024 pts/1S+   19:37   0:00 grep milter
kant:[~]  ps auwx | grep clamd
clamav5639  2.9  2.0  65936 42448 ?Ssl  19:06   0:55
/usr/sbin/clamd
bertrand 12467  0.0  0.0   3800  1024 pts/1S+   19:37   0:00 grep clamd
kant:[~] 

Some inbound mails are refused by kant (because clamd cannot scan all
inbound mails). They remain in sendmail DATA stage and SMTP transaction
aborts due to a timeout. I don't understand why with the same
configuration, MX1 does not works. I'm sure that clamd works fine on
rayleigh, but I'm not sure that it correctly works on kant. I don't see
any information on the logs and all sockets and permissions have been
verified. If I remove clamd support from mimedefang, kant works fine. I
don't understant why only one clamd process can run on kant.

Kernel is 2.6.20.11 (with netfilter ROUTE patch) from kernel.org.

Both run debian/testing. Kant is up to date. Last upgrade was made on
rayleigh 8 days ago.

Any idea ?

Regards,


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Strange trouble with clamd/greylist/mimedefang

2007-06-09 Thread Clint Adams
On Sat, Jun 09, 2007 at 07:51:26PM +0200, BERTRAND Joël wrote:
   Some inbound mails are refused by kant (because clamd cannot scan all
 inbound mails). They remain in sendmail DATA stage and SMTP transaction
 aborts due to a timeout. I don't understand why with the same
 configuration, MX1 does not works. I'm sure that clamd works fine on
 rayleigh, but I'm not sure that it correctly works on kant. I don't see
 any information on the logs and all sockets and permissions have been
 verified. If I remove clamd support from mimedefang, kant works fine. I
 don't understant why only one clamd process can run on kant.

clamav has had some problems particular to sparc in the past, but if
it's working on rayleigh, I wouldn't think that you running it on sparc
is significant.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Strange trouble with clamd/greylist/mimedefang

2007-06-09 Thread BERTRAND Joël

Clint Adams a écrit :

On Sat, Jun 09, 2007 at 07:51:26PM +0200, BERTRAND Joël wrote:

Some inbound mails are refused by kant (because clamd cannot scan all
inbound mails). They remain in sendmail DATA stage and SMTP transaction
aborts due to a timeout. I don't understand why with the same
configuration, MX1 does not works. I'm sure that clamd works fine on
rayleigh, but I'm not sure that it correctly works on kant. I don't see
any information on the logs and all sockets and permissions have been
verified. If I remove clamd support from mimedefang, kant works fine. I
don't understant why only one clamd process can run on kant.


clamav has had some problems particular to sparc in the past, but if
it's working on rayleigh, I wouldn't think that you running it on sparc
is significant.


	Right. For me, one think is very suspect. Milter-greylist nor clamd are 
not able to fork on kant.


The only significative difference for me is the libc release.

Root kant:[~]  dpkg-query -l libc6
...
ii  libc6  2.5-9  GNU C Library: Shared libraries

rayleigh:[~]   dpkg-query -l libc6
...
ii  libc6  2.3.6.ds1-13   GNU C Library: Shared libraries

I have tried to rebuild clamav without any success.

Regards,

JKB


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Strange trouble with clamd/greylist/mimedefang

2007-06-09 Thread Clint Adams
On Sat, Jun 09, 2007 at 08:46:53PM +0200, BERTRAND Joël wrote:
   Right. For me, one think is very suspect. Milter-greylist nor clamd 
   are not able to fork on kant.

What makes you think that they're unable to fork?

   The only significative difference for me is the libc release.
 
 Root kant:[~]  dpkg-query -l libc6
 ...
 ii  libc6  2.5-9  GNU C Library: Shared libraries
 
 rayleigh:[~]   dpkg-query -l libc6
 ...
 ii  libc6  2.3.6.ds1-13   GNU C Library: Shared libraries

2.5 gives you NPTL, which means that threaded programs can have real
threads instead of forking.

If you do a ps -eLf on a glibc2.5 system with numerous clamdscan
processes going, you will hopefully see multiple clamd lines
(same PID, different LWP number).

If you don't, maybe there's an issue with libpthread.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]