Trying not to hijack the thread here, but it seems to fit well in the context:
Does this mean that in the following could happen due to the difference in BSD/Linux SO_REUSEPORT: 1. haproxy process “A” binds say port 1234 2. client A connects to 1234 and keeps the connection open 3. /etc/init.d/haproxy restart 4. haproxy process “B” starts and _also_ binds 1234 5. haproxy “A” is still around, due to client A 6. client B connects to 1234 Am I right to assume that client B can be handled by _either_ haproxy “A” or “B” depending on the hash result underneath SO_REUSEPORT’s implementation? If so, that would explain some issues I had in the past when quickly iterating config changes and restarting haproxy each time, but sometimes getting results that could only have come from an older config? Thanks, Daniel -- Daniel Schneller Principal Cloud Engineer CenterDevice GmbH > On 14.04.2016, at 12:01, Willy Tarreau <w...@1wt.eu> wrote: > > On Thu, Apr 14, 2016 at 10:17:10AM +0200, Willy Tarreau wrote: >> So I guess that indeed, if not all the processes a frontend is bound to >> have a corresponding bind line, this can cause connection issues as some >> incoming connections will be distributed to queues that nobody listens to. > > I said rubish here. It's the same socket that is shared between all these > processes, so there's no issue with all of them picking from the same queue > even if in the end only one picks it. However I want to fix it to make things > cleaner and easier to debug and observe (and not fool netstat as the previous > example showed). > > Willy >
