Hi Jonathan, On Tue, Jul 19, 2011 at 03:52:48PM -0400, Jonathan Simms wrote: > Ok, I think the issue is not related to ubuntu or haproxy, but rather the > execution environment under which I was attempting to restart haproxy. I'm > working on a cluster control program that can reconfigure and restart HAproxy > so that we can do rolling builds in an automated fashion. We're using ruby's > EventMachine library, and I was executing the init.d script via their popen > method. When I rewrote my restarter to instead fork(), clean the environment, > reset all signal handlers, and exec the -sf reload, things started working > properly. > > I'm really at a loss to explain *why* using their popen caused the issue, I > really don't have enough knowledege in that realm to diagnose what's > happening. > I can only guess that it's "something in the environment" causing the issue > (vague enough for you? :) ). Eventmachine is a framework for writing > non-blocking asynchronous (single-threaded) event-driven services, so I could > imagine that there might be some kind of conflict (a signal handler maybe?) > caused by that. I know, it's a weak explanation.
Maybe you're indeed experiencing something in this area. Possibly that the process is passing you a number of file descriptors that were not closed and that are causing trouble. I don't know. > The changes between configurations being reloaded were just adding 'disabled' > keywords on the appropriate server lines for the appropriate backends, so it > wasn't that I was changing bind clauses. OK. > I'm thinking that since this is such a special case, it probably doesn't have > implications for most other haproxy users, however if it would be useful for > you to see (or if you're curious) I'd be happy to do run an strace of the > process and send the results to you. Probably that strace itself will not reveal everything. I don't know any way for a process to block signal delivery to its children, but maybe we're having something like this. Also, not that we're using SIGTTIN/SIGTTOU, which normally are delivered to ttys. It's possible that the popen() call specifically intercepts them. > Anyway, thank you very much for taking the time to reply and I'm sorry to have > led us on something of a wild goose chase :) You're welcome. I always prefer erroneous alerts over untold bugs that reveal very serious at one point for everyone. Best regards, Willy
