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 <wlallem...@haproxy.com> 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. > >> 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. > > -- > William Lallemand >
