Re: 1.6.0 Error: Cannot Create Listening Socket for Frontend and Stats,Proxies

[Susheel Jalali]

Dear Willy and Lukas,

Thank you for your guidance.  Upon implementing your insights, here is
the summed up result:

(1) With Willy’s patch HAProxy starts

(2) But we have to remove listen haproxystats block, as it still cannot
create listening socket for this listen proxy.

Detailed information you have requested is below without and with


-------------------------------------------------------

@Willy:  HAProxy is running on two of our servers that have CentOS 7.1
(Server1) and CentOS 7 (Server2), which support namespace.  Checked
with: ip netns add namespace1 and then ip netns list -->This listed
namespace1

============
WITHOUT Willy’s patch
============
@Lukas and Willy
We installed HAPRoxy 1.5.14 and 1.6.0 on both Server1 and Server2.
1.5.14 starts and functions normally on both.
1.6.0 fails after start without creating pid.


HAProxy 1.5.14
HAProxy 1.6.0

============
WITH Willy’s Patch
============
@Willy
We patched your fixns.diff to namespace.c

Running haproxy in debug mode gives: Oct 20 14:03:35 localhost haproxy:
Starting haproxy: [ALERT] 292/140335 (7337) : Starting proxy
haproxystats: cannot bind socket [<Server_IP:xxxx>]

Upon removing ‘listen haproxystats’ block from HAProxy configuration
(see below), it starts normally

++++++++++
Haproxy configuration
++++++++++
global
       log         127.0.0.1 local2
       pidfile     /var/run/haproxy.pid
       user        haproxy
       group       haproxy
       #daemon
       debug
       chroot      /var/log/haproxy/
       stats socket  /var/log/haproxy/haproxy.stats defaults
       mode        http
       option      abortonclose
       option      http-server-close
[….]
frontend webapps-frontend
       bind          *:80 name xxx
       bind          *:443 name yyy ssl crt /path/to/server.pem
[….]
listen haproxystats
       bind          Server_IP:xxxx
[….]

Thank you.

Sincerely,
-- --
Susheel Jalali
Coscend Communications Solutions
susheel.jal...@coscend.com

www.Coscend.com
-------------------------------------

On 10/20/15 15:02, Willy Tarreau wrote:
> On Tue, Oct 20, 2015 at 11:20:12AM +0200, Willy Tarreau wrote:
>> On Tue, Oct 20, 2015 at 10:54:58AM +0200, Lukas Tribus wrote:
>>>> Dear Willy,
>>>>
>>>> Thank you for your insights. As you advised, below is the output of
>>>> haproxy -f ?cfg -db -V.
>>>
>>> Can you run this through strace (strace haproxy -f ?cfg -db -V) and
>>> provide the output.
>>>

>>> comparison, that would be very helpful as well.
>>

>> seeing how my_socketat() can recover in case setns() returns -1, which
>> happens when default_namespace = -1, which is the default case before
>> initialization :
>>
>> #ifdef CONFIG_HAP_NS
>>         if (default_namespace < 0 ||
>>             (ns && setns(ns->fd, CLONE_NEWNET) == -1))
>>                 return -1;
>> #endif
>
> OK it's clear there's a bug here in my opinion because default_namespace
> is *only* initialized if there are explicit namespaces. I could reproduce
> the issue here, you simply need to build with USE_NS=1 and to declare no
> namespace anywhere. Here's a proposed fix which works for me. Please
> confirm.
>
> Willy
>

Willy’s patch. Your further guidance to fix the item (2) above would be appreciated. Thank you. ATTACHED are strace output from running the following on the same server with the same configuration (including port numbers): >>> Also, if you have the strace output of a successful startup of 1.5.14 for >> Yes definitely. Actually I'm seeing one difference between the two versions, >> it's the introduction of namespaces in 1.6.0. If it was built with support >> for namespaces and they are not supported in the operating system, I'm not

strace.haproxy-1.15.4
Description: Binary data

strace.haproxy-1.6.0
Description: Binary data