I see your point. The thing is, in my setup there is only one frontend. I ran into this when writing an upgrade script: 1) disable frontend 2) perform update of the node with haproxy - this may result in restart of haproxy 3) wait for other nodes to be updated 4) enable frontend
Problem is, in step 2) the haproxy starts with enabled frontend. Since other nodes in the platform may not have been properly updated yet, this is highly undesirable. What I therefore need is to start the haproxy with disabled frontend and then enable it manually. Thanks for the comments, regards. Ondrej On Mon, Apr 25, 2016 at 4:57 PM, Willy Tarreau <w...@1wt.eu> wrote: > Hello, > > On Mon, Apr 25, 2016 at 01:47:23PM +0200, Ondrej Stumpf wrote: > > That is not the issue. I'm talking about the "disabled" keyword in > HAProxy > > configuration file. That can be used in the "frontend" section (among > > others) to start the frontend without actually binding to a port. To > quote > > the docs: > > "The instance will still be created and its configuration will be > checked, > > but it will be created in the "stopped" state and will appear as such in > > the statistics. It will not receive any traffic nor will it send any > > health-checks or logs." > > However, if you use that keyword, not only the frontend does NOT appear > in > > stats, but it also cannot be enabled via stats. The fix that I propose > > fixes it - the frontend is after startup visible in stats (in STOP state) > > and can be enabled via "enable frontend xyz". > > Actually your patch introduces a bug where there is not. It results in > the frontend being always started and always taking traffic, so people > who use "disabled" to switch between one frontend and another will get > the two active at once. > > People who use the "disabled" keyword generally want to have two config > sections for the same feature, but used under various conditions, for > example a first section for use under normal conditions and a second one > with aggressive filtering for use when under attack. > > As you can see in your case, the following setup results in the same port > being bound twice, as reported by netstat : > > frontend normal > bind :80 > ... > > frontend filtered > disabled > bind :80 > ... > > What is currently being done exactly matches what is indicated in the doc. > > As indicated by Pavlos, there's no way to re-enable a frontend that has > been either shutdown or disabled. The reason is double : > - you can't unbind then rebind otherwise all privileged ports will be > definitely lost once the privileges are dropped upon startup. > > - you don't want to remain bound because as long as you're bound you're > taking incoming connections that are not properly delivered to the > other listener. > > Regards, > willy > >
