On Wed, Oct 07, 2026 at 11:29:05AM +0200, Lukas Tribus wrote:
> I'm saying all of this is only relevant when zero-warning is enabled,
> which is an explicit opt-in choice and so is diag mode. Actually the
> administrator has opted into 2 optional flags, with the intention to
> not be blindsided by config mistakes.
Not exactly, there's the "zero-warning" statement in configs that's
clearly intended to catch warnings, and that one will trigger with
-dD that's essentially used as a final check for human mistakes in
the config. When it's use this way I think it's not dramatic.
> I would refrain from backporting new warnings to stable branches; I
> don't think new diagnostic warnings between bugfix releases are
> desired at all.
We don't backport alerts nor warnings precisely because they can
break existing setups (those with "zero-warning"). However we do
occasionally backport diag warnings, and precisely some which are
new warnings are sometimes backported as diags so that they do not
break configs. I found a few such examples like this one, backported
to 3.0:
41ca89bc6f ("MEDIUM: log: relax some checks and emit diag warnings instead
in lf_expr_postcheck()")
+ ha_diag_warning("parsing [%s:%d]: format alias '%s' used from %s '%s' may
not work as expected (item depends on HTTP proxy mode).\n",
or this one in 3.2:
5d021c028e ("BUG/MINOR: check: only try connection reuse for http-check
rulesets")
+ diag_warning(ret, "parsing [%s:%d] : 'server %s': check-reuse-pool is
ineffective for non http-check rulesets.\n", srv->conf.file, srv->conf.line,
srv->id);
However I'm noticing that in 3.5-dev1 we committed this:
960fa1c921 ("BUG/MINOR: cpu-topo: use ha_diag_notice() to report thread
creations")
and it states:
Using ha_diag_warning() to report the number of threads created resulted
in warnings being counted and possibly an error being fired when combined
with -dW (...)
Which is exactly what you're documenting. I didn't realize by then that it
was due to a behavior change but it seems that it already got accepted as
a matter of fact anyway.
> I cannot imagine people running untested new haproxy branches in
> pipelines with -dD -dW enabled and then complain about config
> rejection.
It's not new haproxy branches that worries me it's really that people
want to check for mistakes or stuff that will probably not work as
expected, which is what -dD provides.
> However people loose a lot of time with things discussed in the other
> thread with Björn.
Yes I understand that.
> Before ced4148401 a "-c -dD -dW" returned a zero exit code even when
> diagnostic mode and zero warning where enabled and warnings printed.
Yes and that really was the intent before 3.5-dev1 which seems to have
accepted this new situation.
> The config checker would need to be run through something external
> like "chronic -e" to actually return non-zero.
Such messages were *really* not meant to be used by automated systems,
I initially created that to help me audit users config to find stupid
issues in them like the classical duplicated cookie. This is why I'm
worried that the patch hides an intent to use it as a startup validation,
which it was absolutely not made for, and that may make us reconsider the
development of new diagnostics by fear of breaking stuff.
> I think it boils down to the fact that we are talking about 2
> fundamentally different use cases:
>
> One is the admin deciding to run the configuration through a diag mode
> interactively and manually checking stderr. I would argue that this is
> an extremely rare even when facing behavior issues. It could be used
> as a "first line of defense" in support situations (like the github
> issue template: [ X ] please confirm the config passes without
> relevant warnings through -c -dD).
It was precisely created for this purpose. Otherwise these must be
normal warnings.
> The other use-case is to protect against configuration mistakes,
> including *future* configuration mistakes. If the admin would not be
> convinced that the configuration is correct, he wouldn't just put it
> in without checking more carefully. That is why I think a little
> stderr output does not suffice for this use-case, imho we need a way
> to non-zero exit.
This is the problem I'm having here: by design the diags do not try
to stay conservative and they will flag pretty valid configurations.
They should be perceived as "did you know that ... ?". There is no
way to make them disappear by changing the configuration because the
config is valid, only the usage is suspicious and reported as such.
In fact I would even be tempted to forbid the use of -dD without -c,
to make sure people use it only as a debugging aid, but that wouldn't
change much because they could do it with -c before their service
starts.
> Trying to address both use-cases with the same exact feature/flag may
> not be possible, although I thought the latter use-case could be
> achieved with the combination of zero-warning and diag mode.
Given that, as you reported, it's already used (and incorrectly) to
report warnings and preventing the system from starting for the last
5 versions, I think at the very least we need to integrate your patch
which documents the current behavior. However I'd also like to mention
there that new diags *are* going to be backported from time to time,
and that they are just a debugging aid and that this is absolutely not
supposed to be used as a validity check since pretty valid configs
will trigger it. I just want to limit the situations where people use
that as an extra config check that it is not. However if they just want
to compare reports over time as a preventive way to avoid mistakes,
that might work if they only use that to trigger a message that the
admin will check later.
Willy
