On Mon, Mar 14, 2011 at 12:37:17AM +0100, Willy Tarreau wrote: > On Mon, Mar 14, 2011 at 07:26:30AM +0900, Simon Horman wrote: > > 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. > > Indeed, keeping the fd open would not work. Many scripts do a cp > or mv of the new file over the old one. > > > 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. > > Using a socket would be very nice indeed, because the new process would > be able to pass the config it has on its command line. But that requires > basic socket handling from the new process before we ever start the > polling loop, and for long I've thought this required some code > duplication. I may be wrong though. > > In the mean time, I really think that keeping the master out of the > chroot is the way to go. In my opinion it makes a lot of sense : the > master is the one which owns rights on ports, config, etc... and which > can fork slave process deprived from their permissions. Seen that way, > there's really nothing that justifies jailing the master.
Yes, I think that is an approach worth investigating. I'll see about implementing it.
