So, I looked into using `no log` in non http frontends. But that isn't
sufficient.

For example, if I have:

global
  log-tag "test"
  log localhost:514 len 65535 local2 info info

defaults
  mode http
  timeout connect 100
  timeout server 30000
  timeout client 30000
  log-format "%Tq"

listen mine
  log global
  bind :80
  server localhost localhost:8080

listen health_url
  bind :27000
  mode health
  option httpchk
  no log


I still get [ALERT] 305/160229 (21975) : Parsing [test.cfg:10]: failed to
parse log-format : format variable 'Tq' is reserved for HTTP mode.

However, if I add `log-format "GARBAGE"` to the health_url listener, then
the error goes away.

It seems like if I specify `no log` then the log-format should be ignored,
even if it comes from the default.

On Mon, Oct 9, 2017 at 10:35 AM Thayne McCombs <[email protected]>
wrote:

> Actually, I just remembered that we do have a few tcp mode frontends.
> Maybe that is the reason for the error? Still, is there a way to use a
> default log-format for the http frontends? I'm going to try turning logs
> off for tcp mode frontends and see if that fixes the error.
>
> On Mon, Oct 9, 2017 at 10:22 AM Thayne McCombs <[email protected]>
> wrote:
>
>> I am working on upgrading haproxy from 1.6 to 1.7 on our load balancers.
>>
>> However, on 1.7 with our current config I get the following error:
>>
>> [ALERT] 278/170234 (8363) : Parsing [/etc/haproxy/haproxy-staged.cfg:31]:
>> failed to parse log-format : format variable 'Tq' is reserved for HTTP mode.
>>
>> The log-format directive is in the *defaults* section, which also has a *mode
>> http* directive. Was there a change in 1.7 that made the use of Tq (and
>> other http specific variables) illegal in the log-format of a defaults
>> section?
>>
>> All of my frontends are http frontends. Is there any way I can use a
>> common default log-format for all of them that uses http variables (for
>> example, something like an http-log-format directive) in 1.7? Or do I have
>> to duplicate the log-format for all of my frontends?
>>
>> Thanks,
>>
>> Thayne McCombs
>> Lucid Software, Inc.
>> --
>> *Thayne McCombs*
>> *Senior Software Engineer*
>> Lucid Software, Inc.
>>
>> --
> *Thayne McCombs*
> *Senior Software Engineer*
> Lucid Software, Inc.
>
> --
*Thayne McCombs*
*Senior Software Engineer*
Lucid Software, Inc.

Reply via email to