On Tue, Sep 15, 2020 at 11:52:15AM -0300, Joao Morais wrote: > > > > Em 14 de set de 2020, à(s) 19:14, William Lallemand > > <[email protected]> escreveu: > > > > 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. > > > Cristal clear, thank you so much. Just a few more doubts below. > > > >> 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. > > > Is there any chance to be fast enough to connect and receive a response to a > `show proc` command before the master started the reload process? Sleep 1ms > maybe? Or when master finishes the `reload` response it’ll immediately > shutdown its listener? >
Once it receive the 'reload' it closes the master CLI immediately, it will be really difficult to be fast enough to do a 'show proc'. > >> 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. > > So may I assume fields have 16 bytes and relative pid is represented > as "[was: <0-9...>]", otherwise we have a bug? > Oh right... the space in "[was: ]" is troublesome for cutting the string, we must remove it. Regarding the size of the fields, 16 bytes should be enough but there is the expection of the version field that can be much larger if a dev version with the commit ID in the version is used. -- William Lallemand
