|
That does look like the problem and the solution. Seeing as this bug
hasn't been fixed for nearly 2 months, should we add something to the FAQ
about it?
Thanks,
JT
James Bromberger <jbromberger@xxxxxxxxxxx> wrote on 05/08/2004 20:00:02:
>
> I saw the same thing, and Arthur Bergman here wrote a simple cut down
> of the test used in ldirectord to get to the error, somewhere in
> Net::SSLeay. See:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254671
>
>
> Its the SSL test you have. Try either plicating the SSL test by only
> doing it once every so often (checktype=60 to do it once per minute),
> or just do a connect test (checktype=connect).
>
> HTH,
>
> James
>
>
> On 4 Aug 2004, at 01:32, Jonathan Trott wrote:
>
> > We have had ldirectord 1.88 running on our Fedora Core 1 cluster for a
> > few
> > months now with occasional crashes of the active server. I have
tracked
> > this down to a memory leak, probably in perl, that is causing
> > ldirectord
> > to take up more and more memory on the machine until it runs out and
> > starts killing processes.
> > For example, after 8 days uptime ldirectord was consuming 487MB of RAM
> > until I rebooted it this morning.
> > Does anyone have any idea where I should start looking to patch perl
to
> > fix this problem?
> > Perl is 5.8.3 that comes with Fedora Core 1. I have already checked
> > CPAN
> > for updates to Net::SSLeay as that has come up before with leakages
and
> > the version that is installed (1.26) is much newer than the version
> > that
> > had a memory leak (1.20 or 1.21). For completeness, this is my
> > ldirectord.cf:
> >
> > checktimeout=6
> > checkinterval=2
> > autoreload=yes
> > #logfile="/var/log/ldirectord.log"
> > logfile="local0"
> > quiescent=no
> >
> > virtual=192.168.100.1:80
> > real=192.168.11.11:80 masq
> > real=192.168.11.12:80 masq
> > real=192.168.11.13:80 masq
> > real=192.168.11.14:80 masq
> > fallback=127.0.0.1:80
> > service=http
> > request="/serverstate/"
> > receive="server up"
> > scheduler=rr
> > #persistent=5
> > #netmask=255.255.255.255
> > protocol=tcp
> >
> > virtual=192.168.0.1:80
> > real=192.168.11.11:80 masq
> > real=192.168.11.12:80 masq
> > real=192.168.11.13:80 masq
> > real=192.168.11.14:80 masq
> > fallback=127.0.0.1:80
> > service=http
> > request="/serverstate/"
> > receive="server up"
> > scheduler=rr
> > #persistent=5
> > #netmask=255.255.255.255
> > protocol=tcp
> >
> > virtual=192.168.100.1:443
> > real=192.168.11.11:443 masq
> > real=192.168.11.12:443 masq
> > real=192.168.11.13:443 masq
> > real=192.168.11.14:443 masq
> > fallback=127.0.0.1:443
> > service=https
> > request="/serverstate/"
> > receive="server up"
> > scheduler=rr
> > #persistent=5
> > #netmask=255.255.255.255
> > protocol=tcp
> >
> > virtual=192.168.0.1:443
> > real=192.168.11.11:443 masq
> > real=192.168.11.12:443 masq
> > real=192.168.11.13:443 masq
> > real=192.168.11.14:443 masq
> > fallback=127.0.0.1:443
> > service=https
> > request="/serverstate/"
> > receive="server up"
> > scheduler=rr
> > #persistent=5
> > #netmask=255.255.255.255
> > protocol=tcp
> >
> > Thanks,
> > JT
> > _______________________________________________
> > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> > or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
> _______________________________________________
> lvs-users mailing list
> lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> http://www.in-addr.de/mailman/listinfo/lvs-users
|
