Re: [PATCH 00/26] Restart of haproxy without dropping connections

On Fri, Mar 11, 2011 at 08:36:49AM +0900, Simon Horman wrote:
> As it stands the master needs the entire configuration as it actually
> starts all the proxies and then forks the workers. This is in order to
> allow the master to know what sockets to bind and unbind. But other than
> that it doesn't care about most of the configuration.

OK that indeed makes sense.

> > The idea would be that we could have all the global config and all
> > proxies in a same struct behind a pointer, and instantiate a new
> > one when reloading the config, then once everything's OK, we can
> > switch the configs and fork new processes. The socket cache just
> > has to be global. And even if we add new listening sockets to this
> > cache when trying to start a new config, it's not dramatic.
>
> Yes, I think that would work. But I wonder if we need to go that far,
> as its probably ok for the master to have an invalid configuration so long
> as we are careful about the (few?) configuration parameters that
> both affect the master and can be changed on restart.

OK.

> > That makes me think that we should most likely keep the master out
> > of the chroot anyway, since it does not participate into network
> > communications, it's not exposed.
>
> I don't have any strong opinions on that either way.
> As it is, having it in the chroot isn't a major burden.

But if it's in the chroot, it can't reread is configuration file.

> But I don't think that changing thing to keep it outside would
> be much trouble at all.

I don't think it should be an issue either, maybe a minor change of the starting sequence. Also, probably that this master will later become the one able to log to real files and to do other things that need to be done outside of the chroot.

> > > As an aside, having the worker pids in the pid file isn't strictly
> > > necessary.
> >
> > Yes it is, because if the master dies, you have no way to tell which
> > children were related to the dead service and must be killed to achieve
> > a sane restart.
>
> True. But the children will detect that the master has died and exit
> of their own accord.

I don't see how the children could easily detect that. There's no reason they'd get a signal, and we should avoid running getppid() or equivalent in the polling loop just to detect a condition which happens once in the life of the process.

> > Well, if master_worker mode with -db doesn't daemonize it, that's already
> > OK then.
>
> Understood. I'll verify that something reasonable occurs on -db.

OK fine.

I'll try to find some time ASAP to review your work, it will be easier to discuss it and you won't have to explain me things that I should have figured by myself if I had tested it :-)

Cheers,
Willy Received on 2011/03/11 06:55