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
going higher and higher. So threadpool->thr_alive isn't decreased and
is completly incorrect.
In my tests the number of threads with libpthread.so is never going higher
than 6 threads. That explains, why a higher load is going to delay all scan
operations more and more.
With libthr.so the value of threadpool->thr_alive is equal with the output of
the ps. It can go very high, but always goes back if no more
work is there to do.
After the maxthreads limit is reached, clamd becomes completly unresponsive
with libpthreads.so.
SIGKILL and SIGSTOP don't work because some (unexisting) worker threads block
on pthread_cond_timedwait(). Only kill -9 helps. Of course, the counter
threadpool->thr_alive is wrong and may cause this problem.
Maybe someone with more threads knowledge can help here. I'll now add some
debug
stuff to see where threadpool->thr_alive is going to be increased and where
it
is decreased. The strange thing is that this works fine with libthr.so.
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.
--
DE
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
