Can you please type slower? I'm having trouble keeping up with your
posts... ;-)
Robin Bowes wrote:
Questions:
Is the plugin loaded twice? Is this normal?
Is this only appearing because I'm running at loglevel 7?
Would adding extra expressions in the multilog filter be the best way to
prevent this?
No. Yes. No. No. (I think)
In more detail this time:
1) The plugin itself won't be loaded more than once if you are running
forkserver, but the initial part of the code (that actually prints the
log message) can get called more than once.
2) There is still a corner case where a new object is created instead of
using the existing object, which calls the logging plugin again (but it
doesn't actually load the plugin again, see #1). I'll see if I can work
out where that is and stomp on it.
3) I run with loglevel 8 for my detailed logs.
4) multilog is very simple, and even a little simpleminded, so I don't
think you can write a filter that will make that line appear in only one
place. However, if we can make sure that the cached object is used
everywhere, you should get at most one log startup line per run (which
means only when the forkserver daemon is started or per each message if
you use the tcpserver method).
Also, a further thought: would it make sense to remove the "maxlevel"
option and use "loglevel" instead? This would mean that:
log messages <= acceptlevel will be logged to the accept log
log messages <= rejectlevel will be logged to the reject log
log messages <= loglevel will be logged to the detailed log
If we make the base logging/adaptive plugin emit a trinary stream, I
would prefer to make the configuration:
log messages <= accept will be logged to the accept log
log messages <= reject will be logged to the reject log
log messages <= detail will be logged to the detailed log
so that it is clear what the default case is...
John
