Hi, On Mon, Jul 07, 2014 at 11:01:05PM +0200, hodor wrote: > Hello, > > On 2014-07-02, 18:39:09, Willy Tarreau wrote: > > > BTW, if abns@ bind() fails during a "-sf" reload, then /tmp/test1.sock of > > > the > > > old HAProxy instance is unlinked/unreachable and thus cannot accept new > > > connections. The new unix@ bind() succeeded, the ".tmp" got renamed, the > > > ".bak" > > > was unlinked. So far so good. But when the abns@ bind() fails, then the > > > whole > > > new HAProxy instance fails and leaves the old instance "degraded". > > > > > > I do not know how to simply fix this. > > > > That's a good point. We have no link()/unlink() on abstract sockets, so > > I don't see how we'll be able to temporarily rename a socket. Since this > > is linux-only, we can consider any os-specific trick available and see if > > one is satisfying (eg: shutdown(RD) followed by listen(), etc). > > I was unable to make it work that way. I used the attached code in one > console, and in the other: > > strace -e trace=bind socat abstract-listen:test,unix-tightsocklen=0 stdio > > I tried a few combinations of shutdown() / listen(), the ordering, ..., > but no luck.
I confirm, this week-end I spent more time reading the code path in the kernel and basically shutdown() is totally ignored for listening unix sockets. And once it's bound, it's bound. Nothing allows them to be temporarily moved aside. > > > I can work around all of those problems by using plain old unix sockets > > > instead, but I like the idea of abstract namespace sockets :). > > > > I like it as well, but you see, another concern I have is the fact that > > any other process -not just haproxy- could be bound to an abstract socket. > > While there are well-known ports for TCP/UDP services, there's no official > > registry of well-known abstract socket addresses and this is a problematic > > point. I suspect that we'll quickly come up with a complement which is a > > random address : we would generate a random address and try to bind. Then > > we would map each abstract name to that random address. It would solve all > > the communications issues within a group of processes belonging to the same > > config space. > > Also with abstract sockets, we lack any access control (apart from the > apparent possibility of collisions). Any process can bind() / connect() > to any name. Sure! > > My gut feeling is that we should use file-system for anything system-wide > > (ie: socat to haproxy), as it's the only way to safely connect two ends. But > > we could use abstract sockets inside the same process or group of processes. > > > > An intermediate mechanism could be to have haproxy automatically prefix > > abstract sockets with the starting process' pid or with a short random. > > But that would kill the possibility of two processes inside different > chroots to communicate efficiently (without some mount --bind tricks). > > (I don't have any practical example of such a setup, though :)) Yes that's the same conclusion I came across this week-end, so I ended up thinking that we should have an "internal" scheme in addition to "abns". The internal one would generate a random or pseudo-random ID that never fails to bind and that never needs to hide during restarts. For now I've handled the pause()/resume() gracefully for abstract sockets, they're totally unbound/rebound. The only drawback is that if you're running with a socket bound to multiple processes, and a new process wants to replace the old one, then fails and signals its failure, in this precise case, only one of the initial processes will be able to rebind to the socket. I feel like it's a very small issue that only needed to be documented and does not even merit a warning in the configuration checker. So I've pushed that and backported into 1.5 as well before everyone starts to get upset by this nasty behaviour. Thanks, Willy
