On Wed, 7 Oct 2026 at 09:00, Willy Tarreau <[email protected]> wrote: > > Hi Lukas, > > On Tue, Oct 06, 2026 at 06:13:18PM +0000, Lukas Tribus wrote: > > Commit 7b01a8dbdd("MINOR: global: define diagnostic mode of execution") > > in 2.4-dev15 introduced diagnostic mode for config warnings. > > > > It was initially designed to be ignored by "zero-warning" mode > > (-dW) and documented accordingly. > > > > Since commit ced4148401 ("BUG/MINOR: diag: always show the version > > before dumping a diag warning") in 3.0-dev3 this changed, and > > zero-warning mode combined with diagnostic messages stop haproxy from > > starting. This appears to be a unintended consequence in ced4148401. > > > > I suggest we respect "zero-warning" mode, which is an opt-in choice an > > administrator consciously makes and stop haproxy from starting when > > diagnostic messages are emitted in zero-warning mode. > > I really feel hesitant on this one. I didn't notice that we broke this > but the intent of the diag mode is not to emit real warnings but doubts > and suggestions. The config is supposed to work fine but the user's > awareness is raised on specific points to ensure they are intentional > and not the result of a failed copy-paste (the duplicate server cookie > being one example). I would like to be sure that at no point we refrain > from adding more such detections because they could cause trouble to > existing deployments. On the other hand, -dD was not initially meant to > be used in production but rather as a diagnostic tool (i.e. manually). > I don't know if users started to enable that by default in order to see > extra info on startup. > > Thus as a rule of thumb I'd say that: > - if people use it by default, we should not count them in warnings > that can trigger a boot failure, and they shouldn't be counted as > boot warnings either as reported in stats (they're currently not); > > - if users continue to use it only for diagnostics (i.e. check a > config before deploying), then I feel less of a problem with > counting them as that might ease some check scripts which want > to detect if anything is reported. > > In the later case we could imagine starting the config first with -c -dW, > and if it passes, try it again with -c -dD -dW, and if it fails, report > the output as diagnostics worth being checked. > > Maybe if we figure that there are distinct use cases (I don't think so > but I could be surprised), we could then extend -dW to take a level and > decide what to block on. But I'm really not fond at all of refusing to > start for what is being detected by -dD if users start to enable it by > default at boot. It was essentially meant for use with -c. > > And yes I understand that we have a bug and we're trying to fix the > doc to match the current state caused by that bug. I don't know if > you or anyone else has opinions on the points above. At least mine as > a developer is that I want to continue to be able to freely add new > extended diags that don't break valid setups.
I'm not saying let's document the behavior because for 5 or 6 release branches we are already doing that. 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. I would refrain from backporting new warnings to stable branches; I don't think new diagnostic warnings between bugfix releases are desired at all. I cannot imagine people running untested new haproxy branches in pipelines with -dD -dW enabled and then complain about config rejection. However people loose a lot of time with things discussed in the other thread with Björn. Before ced4148401 a "-c -dD -dW" returned a zero exit code even when diagnostic mode and zero warning where enabled and warnings printed. The config checker would need to be run through something external like "chronic -e" to actually return non-zero. 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). 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. 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. Lukas
