log loading of configuration files [was Re: Accounting to MySQL not working]

[Josip Rodin]

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.