On Wed, Jun 02, 2010 at 01:46:02PM +0200, Alan DeKok wrote:
When they run it with -X, they'll see the packets as they come in and that's good for the debugging of the per-request logic, but a lot of this initial text will scroll down the screen as if everything in it is all right, and they might miss important information in it.
Well... it shouldn't be too much to ask people to read the debug output. It prints out filenames for a *reason*. Anyone ignoring that because "it's too complicated" is responsible for their own choice.
Then again, there is no clear indication to users which part of the large debug output is important and which part is ignorable, so even if they don't ignore it, it may still actually be too complicated for them to handle.
The issues seen recently here with "unusual" behavior in the config are partly because the server is flexible, in that it allows multiple overlapping configuration sections. It's also partly the responsibility of people who don't examine the configuration files the server is using.
On this specific issue - if, perhaps, there was a message about which setting was read from which file, rather than two asynchronous sets of messages, it would be easier to understand and see any unwanted duplication. For example, add a debug level which would make all references to module instances also include the config filename they were read from. It would be a long output, but doesn't seem very hard to implement (just keep a mapping of module-to-configfilename sets in memory) and would be a good option to have in these cases. Ditto for other setting blocks - virtual hosts, home servers, home server pools. -- 2. That which causes joy or happiness.