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) ?