If you happen to try to define the same constant twice in your Icinga 2 configuration, the resulting config validation error is absolutely not helpful.
How to reproduce
Append the following to /etc/icinga2/constants.conf:
const NotHelpful = 1
const NotHelpful = 2
And run icinga2 daemon -C.
Current behavior
It results in a config validation error, but if you don't know the cause, it's quite unclear why.
[2026-08-13 12:36:37 +0000] information/cli: Icinga application loader (version: v2.16.4)
[2026-08-13 12:36:37 +0000] information/cli: Loading configuration file(s).
[2026-08-13 12:36:37 +0000] critical/config: Error: Constant must not be modified.
[2026-08-13 12:36:37 +0000] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.
Expected behavior
The error should point at the constant being modified, showing the code location in the config like with other validation errors. Ideally, it should show both locations where the constant was (first) defined and where it was modified.
If you happen to try to define the same constant twice in your Icinga 2 configuration, the resulting config validation error is absolutely not helpful.
How to reproduce
Append the following to
/etc/icinga2/constants.conf:And run
icinga2 daemon -C.Current behavior
It results in a config validation error, but if you don't know the cause, it's quite unclear why.
Expected behavior
The error should point at the constant being modified, showing the code location in the config like with other validation errors. Ideally, it should show both locations where the constant was (first) defined and where it was modified.