On Thu, Oct 08, 2026 at 05:12:06PM +0200, Lukas Tribus wrote: > On Wed, 7 Oct 2026 at 14:29, Willy Tarreau <[email protected]> wrote: > > 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. > > Ah, I didn't know that. > > Indeed the function was introduced in the prior commit 7d63efa5f5 which > states: > > Right now the only way to report info that is only displayed in diag > mode with -dD is to use ha_diag_warning(). The problem is that this > then counted as a warning and may result in errors when combined > with -dW, as happens for the CPU topology info: > > > > > [...] > > > 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. > > So right now we use both ha_diag_warning() - reacting to zero-warning > - and ha_diag_notice() ignoring zero-warning. > > So I guess the documentation will have to reflect that the behaviour > is not all diagnostic messages behave the same, unless we decide to > chance the code. > > Something like: > > -dD : enable diagnostic mode. This mode will output extra warnings about > suspicious configuration statements. Some outputs will prevent startup > in "zero-warning" mode.
Yes, and in addition something around: Please note that such diagnostics are essentially meant to raise awareness of humans about some potential latent problems which might be totally intentional, and are subject to change including within a stable branch as well as between machines running the exact same configurations. As such they *will* regularly report valid statements as suspicious, and should only be used combined with "-c" to perform a more in-depth diagnostic. Their result should never be used to prevent a service from starting (what happens when combined with "zero-warning" or "-dW"). Willy
