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
