On Mon, Apr 16, 2018 at 04:13:28PM -0600, Shawn Heisey wrote:
> [ALERT] 105/095234 (7186) : config : backend 'be-cdn-9000', server
> 'planet': unable to use chk-cdn-9000/planet fortracking: disable-on-404
> option inconsistency.
> [ALERT] 105/095234 (7186) : config : backend 'be-cdn-9000', server
> 'hollywood': unable to use chk-cdn-9000/hollywood fortracking:
> disable-on-404 option inconsistency.
> [ALERT] 105/095234 (7186) : Fatal errors found in configuration.
>
> I also tried it with that option in both backend configurations. That
> didn't work either. I don't recall the error, but it was probably the
> same as one of the other errors I had gotten before.
Well, the doc about "track" says this :
track [<proxy>/]<server>
This option enables ability to set the current state of the server by tracking
another one. It is possible to track a server which itself tracks another
server, provided that at the end of the chain, a server has health checks
enabled. If <proxy> is omitted the current one is used. If disable-on-404 is
used, it has to be enabled on both proxies.
So it might have been a different error that you got, possibly caused by an
incompatibility with something else.
> This is on 1.5.12, and I can't really blame you if the "standard" mental
> map you keep of the project doesn't include that version.
Not at all! Versions which are considered supported are still watched,
and eventhough they are updated less often, they still receive fixes if
needed. The latest 1.5 is 1.5.19, so your version is at least affected
by all the issues referenced here :
http://www.haproxy.org/bugs/bugs-1.5.12.html
But none of them seem to involve tracking nor disable-on-404 at first
glance.
> It's got to
> be hard enough keeping that straight for just 1.8 and 1.9-dev! Maybe
> the error I encountered would be solved by upgrading. Upgrading is on
> the (really long) todo list.
There are two distinct things :
- getting issues fixed
- upgrading to get new features or support
As long as an issue exists in a supported version, it has to be fixed.
Some issues may be the result of an architectural limitation which will
require an upgrade. But most often it is not the case.
Here I'm afraid we're all wasting a lot of time trying to guess what
you have in your config that causes the problem. It's OK if you cannot
post your config here, but please at least post a smaller one reproducing
the issue so that we can help you.
> I do have a config that works. I'm no longer tracking another backend,
> but doing the health checks in the load-balancing backend. The whole
> reason I had migrated server checks to dedicated back ends was because I
> wanted to reduce the number of check requests being sent, and I'm
> sharing the check backends with multiple balancing backends in some
> cases.
That's fine, it's exactly what "track" is made for.
> For the one I've been describing, I don't need to share the
> check backend.
OK but it possibly uncovers another issue in your config.
> I ran into other problems on the application side with how process
> shutdowns work, but resolved those by adding an endpoint into my app
> with the URL path of "/lbdisable" and handling the disable/pause in the
> init script instead of the application. I can now restart my custom
> application at will without any loss, and without a client even noticing
> there was a problem.
OK.
> As of a little while ago, I have solved all the problems I encountered
> on the road to graceful application restarts except the one where a
> backup server is not promoted to active as soon as the primary servers
> are all down.
This is normally done with the "backup" keyword on server lines.
> I described that issue in a separate message to the
> list. I do have a workaround to that issue -- I'm no longer using
> "backup" on any server entries for this service.
Then I don't see how it can work for you. It's a bit confusing I'm afraid.
Willy