On 2014-07-08, 01:24:18, Willy Tarreau wrote: > > 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.
Sounds good. > 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. Just tried it and seems to work great :). It even recovers the abstract sockets smoothly if the new instance fails to start. The problem with plain unix socket being unreachable (unlinked) when the new instance fails to start is still there, though. This can happen when we try to bind() on a new tcp port which is occupied by something else than haproxy. Perhaps this could be solved by delaying the rename(tempname, path) and unlink(backname) after all else is done? Something like .bind_finish() and .bind_rollback() in struct protocol, where .bind_finish() would be for "all is okay" and .bind_rollback() for "something else failed, return the socket to the old haproxy instance"? Those functions could be called after we are reasonably sure nothing else can fail. Thanks, -- hodor
