Hey Michele.

I'm confused as to how "show stat" is correct...

>According to the statistics I have retrieved by means of "show stat" after
enabling disabling servers, it looks like the socket is working as
expected.

But your script does not correspond to this even though it uses "show
stat"...

>After executing the code above, I use a different socket to retrieve the
stats and check that the number of active servers corresponds to the
expected one.

You're sure it's not an issue with this script and the autoheal you have
going on to see the number of expected servers?

If you stop that script and simply disable a server via socat, then refresh
the interface as well as get a new show stat, then enable a server via
socat, then refresh the interface as well as get a new show stat, are your
results as expected?


On Wed, Mar 14, 2012 at 11:46 PM, Willy Tarreau <w...@1wt.eu> wrote:

> Hi Michele,
>
> On Wed, Mar 14, 2012 at 01:07:51PM +0200, Michele Mazzucco wrote:
> > Hello Willy,
> >
> > I have tried to follow your advice, but it didn't solve the matter -- it
> > looks like the problem is not the web interface.
> > After executing the code above, I use a different socket to retrieve the
> > stats and check that the number of active servers corresponds to the
> expected
> > one.
> > This is the log
> >
> >
> > 2012-03-14 10:50:56,568 Enabling reserves
> > 2012-03-14 10:50:56,568 enable server www/i-932dbef7
> > <-- command sent over the socket
> > 2012-03-14 10:50:56,569 Expected 5 active serves, have 4, calling
> change_state() again
> > 2012-03-14 10:50:56,569 enable server www/i-932dbef7
> > <--- command sent over the socket
> > ... server enabled
>
> Just to be sure, is it the disabling of servers which causes trouble or
> enabling them back ?
>
> I'm asking because we (very) recently fixed an issues related to servers
> leaving maintenance mode which was introduced by fixing another issue with
> server tracking, but the regression did not affect any 1.4 releases.
> However, since both fixes have been backported into 1.4.20, it is possible
> there was another corner case we did not identify and which is solved now.
>
> Just in case, would you please check if 1.4.20 still behaves the same ?
> Maybe we're trying to troubleshoot an already fixed issue.
>
> Regards,
> Willy
>
>
>

Reply via email to