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

Hi Simon,

On Mon, Mar 14, 2011 at 07:05:22AM +0900, Simon Horman wrote:
> > But if it's in the chroot, it can't reread is configuration file.
>
> True, I have a slightly dubious way to deal with that.
> After chrooting the configuration file is opened relative
> to the chroot. So you need to do something like this.
>
> edit /etc/haproxy.cfg
> mkdir -p /a/chroot/etc
> cp /etc/haproxy.cfg /a/chroot/etc
> # chmod / chown /a/chroot/etc/aproxy.cfg as needed
> haproxy -sr $(cat /var/run/haproxy.pid) # signal restart

I must say I really don't like this way of dealing with chroots. For me, a chroot is in an empty directory on a read-only file system, otherwise it's useless. The simple fact that the mkdir above is possible makes it possible for the chrooted processes to use that directory to escape the chroot.

> > > 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 it stands that should be easy enough to handle using the same technique
> that is used for the pid file. Of course adding such log directives on
> restart would need to be prohibited. But that probably needs to happen for
> permissions/capabilities reasons anyway. And in any case it should also
> not be difficult.

OK.

> getppid is run once just before before entering the loop.
> And the workers send kill(ppid, 0) while in the loop.
> This only occurs in workers when master_worker mode is enabled.
>
> I didn't pay particular attention to performance considerations.
> If you are worried about that then perhaps the workers could
> kill less often, perhaps using a task.

Yes I think that would be better. The task might be run once a second and will not consume more than one syscall per second whatever the load. I'd be much worried about the kill(ppid, 0) when dealing with 200000 incoming connections per second!

> The feature was a request to allow situations where there is more
> than one process but not detached from the terminal - master_worker
> either without daemon or with -db (patch forthcoming) to play nicely
> with a monitor such as runit[1].
>
> [1] http://smarden.org/runit/

OK, I did not imagine there was a use case for doing that.

> > > > 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 :-)
>
> I don't mind explaining things. But I do look forward to a review.

You'll get it, now that I have released 1.5-dev4, it'll be easier to stay focused on that. I'll probably try that tomorrow if time permits.

Thanks!
Willy Received on 2011/03/13 23:16