Mail Archives: cygwin/2005/01/29/15:23:36
------=_NextPart_000_0038_01C505FD.4AC1D950
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
Hi Reini,
> Reini Urban wrote:
> Mark Pizzolato schrieb:
> > I've been using clamav's clamd under cygwin and noticed that over time
> > the handle count as viewed with TaskManager seems to grow to arbitrary
> > values. I used clamd's option IdleTimeout set to 600 seconds which
> > dramatically reduced the growth rate of the Handle Count. Of course
> > clamd has many things going on that could contribute to handle leakags,
> > so I tried to write a simple program to demonstrate the problem.
>
> Thanks a lot! Maybe we should restart the two daemons daily or weekly?
>
> I will change the default IdleTimeout to 600 secs with the upcoming
> clamav-0.81 release. Which fixes the freshclam proxy problem and some
> OLE issues.
Merely setting IdleTimeout to 600 is currently insufficient due to a bug
which only uses the IdleTimeout parameter for the Initial value used. After
the AV Database is reloaded, the idle timeout is hardset to 30 seconds. The
attached patch (to 0.80 or 0.81) fixes this issue. This patch has been
submitted on the clamav-devel list.
The right choice for the IdleTimeout is a value which is larger than the
largest gap between messages that arrive on your system. This is somewhat
complicated by multiple connections arriving concurrently which is handled
by MaxThreads. MaxThreads has a default value of 10. This would be fine
for most systems, however libclamav uses tmpfile() internally which is NOT
threadsafe (using newlib's tmpfile()) for any system which returns the same
value for getpid() for each thread in a process (i.e. it works fine on Linux
since getpid() on Linux returns a unique value for all threads on the
system). I've submitted changes which address this to the clamav
folks(avoiding tempfile()), but they have not been accepted as yet. To
avoid this issue (and avoid clamd producing "ERROR: ScanStream: Can't create
temporary file." messages), setting MaxThreads to 1 should work, but will
probably affect the behavior of client software that talks to it (possibly
causing deadlocks).
Do you have any insight to help address the underlying socket issues in
threaded programs would clearly help with clamd and every other multi
threaded program which may not even know it has these issues.
- Mark Pizzolato
------=_NextPart_000_0038_01C505FD.4AC1D950
Content-Type: application/octet-stream;
name="idletimeout.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="idletimeout.patch"
--- server-th.c.orig 2005-01-28 15:57:49.848384200 -0800=0A=
+++ server-th.c 2005-01-28 15:58:37.828811900 -0800=0A=
@@ -557,7 +557,7 @@=0A=
*/=0A=
thrmgr_destroy(thr_pool);=0A=
root =3D reload_db(root, copt, FALSE);=0A=
- if((thr_pool=3Dthrmgr_new(max_threads, 30, scanner_thread)) =3D=3D NU=
LL) {=0A=
+ if((thr_pool=3Dthrmgr_new(max_threads, idletimeout, scanner_thread)) =
=3D=3D NULL) {=0A=
logg("!thrmgr_new failed\n");=0A=
pthread_mutex_unlock(&reload_mutex);=0A=
exit(-1);=0A=
------=_NextPart_000_0038_01C505FD.4AC1D950
Content-Type: text/plain; charset=us-ascii
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
------=_NextPart_000_0038_01C505FD.4AC1D950--
- Raw text -