> > > Did you try launching a new haproxy process with the -sf option, without > > > using the master-worker? > > > > Yes, and that also failed with the same "cannot bind" error.
> Without "expose-fd listeners" I suppose? That is correct. > Okay, so it looks like that the unbinding with SIGTOUT does not work on your OS, but the seamless reload seems to work... > According to the code commentary that's a known problem on Solaris, maybe we should add a note in the documentation about it. Good to know. Thanks for looking into this. Anthony ________________________________________ From: William Lallemand <wlallem...@irq6.net> Sent: Monday, December 11, 2017 3:32 PM To: Anthony Via Cc: haproxy@formilux.org Subject: Re: Testing master-worker reloads on HAProxy 1.8 On Mon, Dec 11, 2017 at 11:03:52PM +0000, Anthony Via wrote: > > Did you try the seamless reload using -x without the master-worker? > > I was looking into the "-x" option and it looks like simply adding "expose-fd > listeners" to my stats socket has fixed this issue for me. Sending SIGUSR2 to > the master process now works as expected. Is that option required for this > reload model? "expose-fd listeners" is the option which give the ability to the admin socket to pass the listeners FDs, so this option is mandatory if you want to use the seamless reload. When you use the 'normal' daemon model, you have to specify -x with the path of the socket where you want to retrieve the listeners. Using the master-worker you only need to specify "expose-fd listeners" in the config, and the master will use this socket and reexecute itself with the right "-x" option. > > Did you try launching a new haproxy process with the -sf option, without > > using the master-worker? > > Yes, and that also failed with the same "cannot bind" error. Without "expose-fd listeners" I suppose? > > What is your operating system and version exactly? > > We are using SmartOS: > # uname -a > SunOS ops-dev-lb03 5.11 joyent_20170315T185612Z i86pc i386 i86pc Solaris > > > I think the old processes did not receive the SIGTTOU for an unknown > > reason, or did not unbind once it received the signal. > > > Maybe you could try to compare what's happening on your solaris-like system > > and your ubuntu with the -dR option, using strace on linux and truss on > > solaris. > > I verified using dtrace that the worker is indeed receiving the SIGTTOU > signal from the master (200 times), so the worker must not have been > unbinding. > Okay, so it looks like that the unbinding with SIGTOUT does not work on your OS, but the seamless reload seems to work... According to the code commentary that's a known problem on Solaris, maybe we should add a note in the documentation about it. Regards, -- William Lallemand
