On Tue, Jun 11, 2019 at 09:27:37PM +0200, Tim Düsterhus wrote:
> Reading the log I believe this might actually be a real problem within
> HAProxy. Note the log lines starting at 370 in the attached file:
> line 370: The old worker starts stopping its proxies (due to having
> received the SIGUSR1 from the re-executed master)
> line 401: The client connects
> line 406: The client starts waiting for a response
> line 408: The old worker stopped all proxies
> line 409: The new worker starts
> line 410: The client receives a connection reset
> line 411: The old worker exits
> So clearly there is no *seamless* reload happening here which is the
> very thing the test is testing. The question is: Is the issue with the
> 'abns' socket or is the issue with the 'fd@${testme}' socket? Can
> fd-sockets be seamlessly passed?

That's an excellent question. I tend to think we cannot pass them by
definition since the fd is supposed to be passed by the caller in
this case! So very likely the issue stems from the fact that we're
relying on passing an fd in a situation where it has no chance of
being passed due to the way it's configured.

I don't know if we can run a vtest client against an abns address, in
which case a solution could consist in using exclusively abns sockets
for the tests. Another solution could consist in not using the client
at all and relying on health checks instead to send the request. But
in all cases that's racy.

> In any case this is a bad test, because it is inherently racy.

Yes I agree. Typically the type of thing I tend to be cautious about
in regression testing, I know that when we try to go too far in this
direction we tend to spend more time and energy fixing problems
invented from scratch in the test scenarios instead of addressing
real issues. There's a mid-point to find, which is always difficult.

Note, we could also imagine having a few "unit" tests that require a
very specific environment and which would be compatible with testing
by hand (e.g. binding to a fixed port, etc). I see how this could be


Reply via email to