Hi Pieter, On Tue, Nov 21, 2017 at 04:34:16PM +0100, PiBa-NL wrote: > Hi William, > > I was intending to use the new feature to pass open sockets to the next > haproxy process. > And thought that master-worker is a 'requirement' to make that work as it > would manage the transferal of sockets. > Now i'm thinking thats not actually how its working at all.. > I could 'manually' pass the -x /haproxy.socket to the next process and make > it take over the sockets that way i guess.?
Yes it's the intent indeed. Master-worker and -x were developed in parallel and then master-worker was taught to be compatible with this, but the primary purpose of -x is to pass FDs without needing MW. > (How does this combine with nbproc>1 and multiple stats sockets bound to > separate processes?) There's a special case for this. Normally, as you know, listening FDs not used in a process are closed after the fork(). Now by simply setting "expose-fd listeners" on your stats socket, the process running the stats socket will keep *all* listening FDs open in order to pass them upon invocation from the CLI. Thus, even with nbproc>1, sockets split across different processes and a single stats socket, -x will retrieve all listeners at once. > Though i can imagine a future where the master would maybe provide some > aggregated stats and management socket to perform server status changes. > Perhaps i should step away from using master-worker for the moment. I think you don't need it for now and you're right that we'd all like it to continue to evolve. Simon had done an amazing work on this subject in the past, making a socket server and stuff like this but by then the internal architecture was not ready and we faced many issues so we had to drop it. But despite this there was already a huge motivation in trying to get this to work. This was during 1.5-dev5! Since then, microservices have emerged with the need for more common updates, the need to aggregate information has increased, etc. So yes, I think that the reasons that motivated us to try this 7 years ago are still present and have been emphasized over time. Maybe in a few years the master-worker mode will be the only one supported if it provides extra facilities such as being a CLI gateway for all processes or collecting stats. Let's just not rush and use it for what it is for now : a replacement for the systemd-wrapper. > However the -W -D combination doesn't seem to (fully) work as i expected, > responses below.. As mentionned in the other thread, there's an issue on this and kqueue that I have no idea about. I'm suspecting an at_exit() doing nasty stuff somewhere and some head-scratching will be needed (I hate the principle of at_exit() as it cheats on the stuff you believe when reading it). > I would prefer to do both 'catch' startup errors and daemonize haproxy. > In my previous mail i'm starting it with -D, and the -W is equivalent of the > global master-worker option in the config, so it 'should' daemonize right? > But it did not(properly?), ive just tried with both startup parameters -D -W > the result is the same. > The master with pid 3061 is running under the system /sbin/init pid 1, > however the pid 2926 also keeps running i would want/expect 2926 to exit > when startup is complete. > > I just also noted that the 2926 actually becomes a 'zombie'.?. that cant be > good right? It's *possible* that this process either still had a connection and couldn't quit, or that a bug made it believe it still had a connection. Given that you had a very strange behaviour with -D -W, let's consider there's an unknown issue there for now and that it could explain a lot of strange behaviours. > It seems to work properly the way you describe.. (when properly demonized..) > Sorry for the noise on this part.. No pb, feedback is always very useful, and mistakes in feedback are as much unavoidable as mistakes in the code :-) > > Unfortunately signals are asynchronous, and we don't have a way yet to > > return > > a bad exit code upon reload. But we might implement a synchronous > > configuration notification in the future, using the admin socket for > > example. > Being able to signaling the master to reload over a admin socket and getting > 'feedback' about its results would likely also solve my 'reload feedback' > problem. > Lets consider that a feature request :). I really think it will eventually happen because the master is the most interesting process to act on in multi-process environments. I'm just cautious, observing how much nbproc continues to be used once threads start to appear in configs : if we end up always using a master with a single worker made of multiple threads, maybe the master socket will be very limited. If nbproc keeps making sense despite threads, a master socket will need to do a lot of stuff. Thanks! Willy
