Hi Joao, On Wed, Jul 23, 2025 at 11:55:41AM -0300, Joao Morais wrote: > > Hi William, I couldn’t follow close enough on everything that's happening on > the master socket land, wondering if there is something you could add or > change on this previous talk we had in the past. Thank you! > > --jm > > > > > On 14 Sep 2020, at 19:14, William Lallemand <[email protected]> wrote: > > > > Hello, > > > > On Mon, Sep 14, 2020 at 12:09:21PM -0300, Joao Morais wrote: > >> Hello list, I'm working on an automation around haproxy process > >> lifecycle in master-worker mode. It's working nice but I'm not > >> confident that all premisses I used are correct. Please provide some > >> guidance if I did any wrong assumption, RTFM link is welcome as usual. > >> > > > > The documentation about the master CLI is probably light about how it's > > implemented so I'll try to be as clear as possible. > > > >> First of all I figured out that master cli will "connection refused" > >> after a reload cmd during the start of the new worker. I'm using a > >> unix socket but I assume the behaviour would be the same using > >> ip+port. > > > > Indeed, during a reload all connections to the master CLI are closed > > because the master process is executed again. There is currently no > > mecanism to recover a previous connection from the previous process. > > That's the same with the unix socket or an IP socket. > > > >> I'm also using a successful connection as the meaning of a > >> finished reload process, failed or not. Please let me know if there is > >> a way to be notified, I'm retrying to connect within a for-loop and a > >> growing sleep between attempts. > > > > Unfortunately there is no way to be notified, that was part of the next > > things I wanted to implement in the master process. But you are right, > > once you can connect, the reload is finished. > >
We now have a synchronous "reload" command on the master CLI since version 2.7. https://docs.haproxy.org/3.2/management.html#reload What it does is that it keeps alive the master CLI connection doing the "reload", until the reload is done. Once it's done, it will dump a Success status, followed by the startup logs, and then close the connection. > >> Another assumption I made is that if I don't have any worker in the `# > >> workers` list, it means that the last reload failed. I've observed > >> that as soon as the master cli accepts connections again, the new > >> worker is already there provided that the reload didn't fail. > > > > That's correct. You can also check the number of reloads the worker had. > > If it reloaded correctly this number is 0 for the new workers. > > > >> I also observed that the `show proc` output isn't that > >> machine-friendly, anyway it's not a big deal, some regex does the job > >> and I'm assuming the lay out is immutable. Maybe I missed some > >> optional json output in the doc? > >> > > It is supposed to be splitable easily with cut, but if that does not > > work this is a clearly a bug. Not much changed in this area, it's a bit simpler because nbproc disappeared long ago, so you can only have one active worker at the same time. The relative PID column was also removed because of this. Also the program section was removed in 3.3 so this disappeared as well. We still don't have JSON though, but if this is something you need that could be doable. Regards, -- William Lallemand
