On Sun, Mar 13, 2011 at 11:16:33PM +0100, Willy Tarreau wrote: > 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.
Our image of chroots is slightly different, though I do take your point. Unfortunately I'm not sure of a good alternative to re-opening the file. Keeping the fd open would be way to fragile as editors often create a new file rather than editing in-place. I guess we could pipe the configuration over a socket or something, and we could also use the same socket as the error-condition detector that you were discussing in an earlier email. > > > > 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! Sure, I'll move it into a worker. > > 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. It wasn't immediately obvious to me either, but I think it does make sense. > > > > > 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. Great. I live in Tokyo. Thankfully I am ok. But as a result of the recent earthquakes in Japan I am likely to experience rolling blackouts over the next few weeks starting tomorrow. So I may be a little unresponsive from time to time. Your understanding is appreciated.
