On 19 Jan 2017, at 07:46, Willy Tarreau <[email protected]> wrote: > On Wed, Jan 18, 2017 at 08:14:24PM +0100, Guillaume de Lafond wrote: >> >> >> >>>> defaults >>>> log global >>>> log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ >>>> h=%Th/i=%Ti/R=%TR/w=%Tw/c=%Tc/r=%Tr/d=%Td/a=%Ta/t=%Tt\ %ST\ %B\ %CC\ %CS\ >>>> %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r >>>> mode http >>>> option httplog >>> >>> The issue is here, you are mixing "log-format" and "option httplog". >>> At first you set your custom format, but "option httplog" will reset the >>> default one. >>> Remove "option httplog" and it should work. >> >> Right, it works :) Thank you! >> >> The documentation does not say anything about the conflict between the two >> variables. And my feeling while reading it, is that the ???log-format??? wins >> against the "option httplog??? even if they are in the same section. > > I think we should update the doc to mention that nowadays, "option httplog" > is just an alias for "log-format something" and that as such it overrides > any previous log-format.
DOC: log-format/tcplog/httplog overrides previous log-format/tcplog/httplog
logformat-overrides-previous-log.patch
Description: Binary data
>> Maybe we should emit a warning about the conflict as the log-format is >> silently ignored in this case or do not allow at all to have ???option >> httplog??? (or "option tcplog") with ???log-format??? in the same section. > > It's difficult to do this due to the fact that we inherit settings from > the defaults section. We don't want a frontend to emit a warning when > it uses option httplog while it had inherited the log-format from the > defaults section. However I think we could add such a warning when the > defaults section contains both since we know that by definition it does > not inherit the settings from anywhere else. > > Are you interested in trying to implement this ? I think it can be done > in cfgparse.c where "httplog" is checked. There are already checks for > a previous logformat_string in order to free it, I think that we can > insert a check before this so that if curproxy == &defproxy and > logformat_string is set, then we warn that a previous log-format was > already specified in this section and will be overridden. The same > test should be added in "tcplog" and in "log-format". In fact you > just need to search "logformat_string", there are not that many. Please find the patch to add a warning when the log-format is override in a “defaults” section. MINOR: config parsing: add warning when log-format/tcplog/httplog is overriden in defaults sections
warning_for_log_format_override.patch
Description: Binary data
This patch does not catch the same thing in a frontend like :
frontend MyFrontend
bind 127.0.0.1:8087
log-format "%Tt”
option httplog
log-format "%Tt %Tr”
default_backend TransparentBack_http
To handle this in a frontend, I think I have to create a new variable in the
proxy struct that could be used to track previous declaration inside a “proxy" ?
in pseudo code :
...
if (config_directive_line == “XXXX")) {
if (curproxy->tmp_config[curproxy->cap]["XXXX"])
{
previous_logformat = curproxy->tmp_config[curproxy->cap]["XXXX”];
oldfile = previous_logformat[0];
oldlinenum = previous_logformat[1];
oldlogtype = previous_logformat[2];
Warning("parsing [%s:%d]: ‘%s' override previous '%s’
(%s:%d).\n”, file, linenum, XXXX, oldlogformat, old file, oldlinenum);
}
curproxy->conf.logformat_string = …;
curproxy->tmp_config[curproxy->cap][“XXXX"] = array(file, linenum,
“XXXX”);
}
….
If curproxy->tmp_config is an array, we may use it to check other config
variables that should not be duplicate in the same "proxy” like :
frontend MyFrontend
mode tcp
….
mode http
…
--
de Lafond Guillaume
