[Linux-HA] ldirectord 1.99 fails to recognize HTTPS server being shut down

[Horms]

On Wed, Jul 06, 2005 at 12:19:44AM +0200, Volker Dormeyer wrote:
>  * On Tue, 5 Jul 2005 11:14:58 +0900,
>  * Horms <horms at verge.net.au> wrote:
> 
>  > On Mon, Jul 04, 2005 at 11:56:29PM +0200, Volker Dormeyer wrote:
>  >> @Horms: Maybe you can remember, some time ago I reported this problem
>  >> with the httpmethod patch I sent and the HTTPS check. Maybe the report
>  >> was lost within numbers of emails you receive every day. Sure, this
>  >> patch is not the best way to do this. That's why I replaced Net::SSLeay
>  >> by LWP (shouldn't have a memory leak anymore) in another patch.
> 
>  > Could you please rediff your change against CVS, and send it here
>  > again? Appologies, but I am not sure what happened to my last copy.
> 
>  > But I am certainly very enthusiastic of anything that leads to not
>  > using Net::SSLeay.
> 
> apologise, this email is a bit long, but I would like to provide the
> details...
> 
> please find attached the patch, I mentioned in my previous email. It
> removes the dependency of Net::SSLeay but creates a new one to Crypt::SSLeay
> (libcrypt-ssleay-perl in Debian) which is by default used by LWP.
> 
> The patch removes the check_https() and check_https_child() functions and
> points ldirectord to use check_http() for HTTPS checks, as well. All
> the tests I did for HTTP and HTTPS worked fine (RS = real server):
> 
> 	|  HTTP  |
>    #	| method | Test			 | Response	| Result
> --------+--------+-----------------------+--------------+-------------
>    1.	| GET	 | RS ok, Content ok	 | HTTP 200	| RS enabled
>    2.	| GET	 | RS ok, Content bad	 | HTTP 200	| RS disabled
>    3.	| GET	 | RS ok, Content ok	 | HTTP 301	| RS enabled
>    4.	| GET	 | RS failed	 	 | ICMP error	| RS disabled
>    5.	| GET	 | RS ok, SSL neg. fails | Timeout	| RS disabled
>    6.	| HEAD	 | RS ok		 | HTTP 200	| RS enabled
>    7.	| HEAD	 | RS ok		 | HTTP 301	| RS enabled
>    8.	| HEAD	 | RS failed		 | ICMP error	| RS disabled
>    9.	| HEAD	 | RS ok, SSL neg. fails | Timeout	| RS disabled
> 
> HTTP 30x redirects are followed for HTTPS as well, now.
> 
> Because of the memory leakage doubts, I wrote a few test scripts
> independent from ldirectord and ran many tests with ldirectord itself a
> few month ago - even some of them ran over night.
> 
> With one of the test scripts, I was able to reproduce the memory leakage
> within Net::SSLeay (I was quite impressed, it leaked for every
> connection request). But, I could not reproduce a memory leak with
> Crypt::SSLeay, so far.
> 
> With ldirectord, I ran the tests with two virtual servers (the first one
> used HTTP GET, the second one used HTTP HEAD to check the real servers).
> 
> I measured the process size via /proc/<PID>/status.
> 
> ldirectord starts constantly with the following process size on my
> system:
> 
> 	VmSize:     9520 kB
> 	VmLck:         0 kB
> 	VmRSS:      7768 kB
> 	VmData:     5372 kB
> 	VmStk:        16 kB
> 	VmExe:       996 kB
> 	VmLib:      2924 kB
> 	
> After a few minutes RSS grows by 2 pages or 8 kb:
> 
> 	VmSize:     9520 kB
> 	VmLck:         0 kB
> 	VmRSS:      7776 kB
> 	VmData:     5372 kB
> 	VmStk:        16 kB
> 	VmExe:       996 kB
> 	VmLib:      2924 kB
> 
> These values seem to stay forever then, except when a real server fails
> in a way where ldirectord is able to connect to it, but the real server
> in fact is not able to answer within the <negotiatetimeout>. In this
> case, I could see a slight increasement of the process memory usage.
> This memory doesn't seem to be freed again, even if the real server is
> alive again. But this it true for the plain HTTP part, as well.
> 

There doesn't seem to have been a problem with HTTP and memory usage
in the past, so I guess the same is true of this new HTTPS check.
I have gone ahead and put it into CVS, that should give it a bit
of a run for its money once the next release comes out.

-- 
Horms