Re: [lvs-users] Patches for ldirectord

To: horms@xxxxxxxxxxxx
Subject: Re: [lvs-users] Patches for ldirectord
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: "Sean E. Millichamp" <sean@xxxxxxxxxxx>
Date: Wed, 22 Apr 2009 09:07:58 -0400
Simon Horman wrote:
> One or two things about the patch posting, as I hope you send some
> more patches some day :-)
Hi Simon,

Thanks for the feedback.  I wouldn't be surprised if you get at least a 
couple of more patches from me.

> On Tue, Apr 21, 2009 at 01:51:41PM -0400, Sean E. Millichamp wrote:
>> ldirectord-01-cleanup-forked-children.patch:
>> I observed that when ldirectord exits while using fork=yes the children  
>> forked to perform the checks are not killed or otherwise cleaned up and  
>> continue running.  This patch sends the children SIGTERM when ldirectord  
>> exits.
> I'm surprised that this is needed. But it isn't the first time this
> has come up, so I'm happy top put the change in.
The children were left behind on every test in my testing environment.  
It appears to have been a prevalent problem in our production 
environment as well.  I agree that it looks like it shouldn't be needed, 
but it does fix the problem for us.
>> ldirectord-02-dont-disable-realservers-in-forking.patch:
>> When using fork=no there is a sanity check on the state of the LVS  
>> pools, and ldirectord modifies them as necessary.  If there are  
>> realservers already present in existing pools ldirectord doesn't disable  
>> them until checks can complete.  However, when using fork=yes this same  
>> sanity check is performed, but all realservers are set down until one  
>> check passes successfully.  This patch fixes this behavior so that the  
>> realservers are not set down initially when fork=yes
> I'm not sure that I completely understand the difference in desired
> behaviour between forking and non-forking.
Well, it isn't so much as a desired difference, as a desired similarity 
to fix an existing difference.  In both the forking and non-forking code 
paths ldirectord starts by, among other things, calling ld_start().  In 
ld_start it goes to apparently great lengths to scan the pre-existing 
kernel LVS tables (if any) and remove any realservers listed in the 
table that aren't in the config, add any realservers with an initial 
weight of 0 to the server_down state, and leave the other realservers at 
whatever weight they initially started set at.  However, if in forking 
mode the run_child function put all realservers into a forced down mode, 
setting their weights to 0.  This had the effect of interrupting the 
virtual services until the first check could complete on each system.

By applying this patch it merely removes that initial force-down setting 
and causes it to actually behave similarly to non-forking mode.  At 
least, that was the intent behind the patch. :)



Please read the documentation before posting - it's available at: mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

<Prev in Thread] Current Thread [Next in Thread>