On Aug 3, 2010, at 11:41 AM, Willy Tarreau wrote: > Hi Nick, > > On Tue, Aug 03, 2010 at 10:11:53AM -0500, Nick Hilem wrote: >> >> On Aug 3, 2010, at 1:52 AM, Willy Tarreau wrote: >> >>> Hi Nick, >>> >>> On Mon, Aug 02, 2010 at 11:13:29PM -0500, Nick Hilem wrote: >>>> I have HAProxy, 1.3.15, on the frontend of a few Ubuntu 9.04 instances >>>> with the following haproxy.cfg that are distributing to a couple >>>> apache/passenger instances. My problem is that if I... >>>> curl http://localhost/ >>>> It sits for awhile then returns a 504 Gateway Timeout. However if I... >>>> curl http://localhost:7000/ >>>> Which passenger is listening on, it returns fairly quickly with the page I >>>> would expect to see. >>> >>> That's kinda weird. One (unlikely) possibility would be that the server >>> responds differently when it does not see its port in the request. Could >>> you force it to see if it changes anything : >>> >>> curl -H "Host: localhost" http://localhost:7000/ >> >> Works. >> >>> curl -H "Host: localhost:7000" http://localhost/ >> >> Fails. > > OK > >> I get the following errors when I add the -d, and reload HAProxy. >> >> [ALERT] 214/100529 (26463) : Starting proxy passenger_proxy: cannot bind >> socket >> *** [err :: web01.mydomain.com] [ALERT] 214/100529 (26463) : Starting proxy >> passenger_proxy: cannot bind socket >> *** [err :: web01.mydomain.com] [ALERT] 214/100529 (26463) : Starting proxy >> health_check: cannot bind socket >> *** [err :: web01.mydomain.com] [ALERT] 214/100529 (26463) : Starting proxy >> admin: cannot bind socket >> >> :( > > No, that's very cool, it means there is something wrong somewhere > else because the ports are already bound. Either an older version > of haproxy is still running with an old conf, or something is bound > to the port, preventing it from starting. I think that for a long > time you've been running your tests on an old broken config while > you were believing it was the new one. > > Using "netstat -lntp" you'll be able to figure what process is bound > to the ports and kill it before restarting haproxy with -d. > > Regards, > Willy
r...@web01:/var/log# ps aux | grep haproxy root 13026 0.0 0.0 2420 524 ? Ss 20:05 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid root 14442 0.0 0.0 3420 764 pts/1 R+ 20:50 0:00 grep haproxy r...@web01:/var/log# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:60001 0.0.0.0:* LISTEN 13026/haproxy tcp 0 0 0.0.0.0:9100 0.0.0.0:* LISTEN 13026/haproxy tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 13026/haproxy tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN 17349/munin-node tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1069/sshd tcp 0 0 0.0.0.0:7000 0.0.0.0:* LISTEN 12693/apache2 tcp 0 0 0.0.0.0:7001 0.0.0.0:* LISTEN 12693/apache2 tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 13600/master tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 13026/haproxy tcp 0 0 0.0.0.0:2812 0.0.0.0:* LISTEN 13033/monit tcp6 0 0 :::22 :::* LISTEN 1069/sshd The netstat only appears to show the latest HAProxy being run and the config file that I've been using is the one specified in the command. You were right that the errors above seem to indicate an older HAProxy not being shut down properly, but even if I ensure a full stop and removal of pid before issuing a start... that particular error goes away but the initial problem still persists. After doing some more digging, I've noticed that if I... curl http://localhost/ ...immediately after a restart/start it will go through successfully, but then subsequent calls and/or if I don't issue the command quick enough, will timeout. But the calls to... curl http://localhost:7000/ ...will still go through. So it appears as though it can bind, but then relinquishes control to something else?
