Currently, when processing a `CheckResult`, it will first trigger an
`OnNextCheckChanged` event, which is sent to all connected endpoints.
Then, when `Checkable::ProcessCheckResult()` returns, an `OnCheckResult`
event is fired, which is of course also sent to all connected endpoints.
Next, the other endpoints receive the `event::SetNextCheck` cluster
event followed by `event::CheckResult`and invoke
`checkable#SetNextCheck()` and `Checkable#CheckResult()` with the newly
received check. So they also try to recalculate the next check
themselves and invalidate the previously received next check timestamp
from the source endpoint. Since each endpoint randomly initialises its
own scheduling offset, the recalculated next check will always differ by
a split second/millisecond on each of them. As a consequence, two Icinga
DB HA instances will generate two different checksums for the same state
and causes the state histories to be fully resynchronised after a
takeover/Icinga 2 reload.
A day specification like "monday -1" refers to the last Monday of the month.
However, there was an off by one if the first day of the next month is the same
day of the week, i.e. a Monday in this example.
LegacyTimePeriod::FindNthWeekday() picks a day to start the search for the day
in question. When given a negative n to search for the n-th last day, it
wrongly used the first day of the following month as the start and counted it
as if it was within the current month. This resulted in a 1/7 chance that the
result was one week too late.
This is fixed by using the last day of the current month instead.
As seen in the recent GHA run for #10102, the two Windows Actions have
failed. The output log contains:
> DEBUG: 27+ >>>> ctest.exe -C "${env:CMAKE_BUILD_TYPE}" -T test -O $env:ICINGA2_BUILDPATH/Test.xml
> --output-on-failure --log_level=all
> CMake Error: Unknown argument: --log_level=all
> CMake Error: Run 'ctest --help' for all supported options.
After consulting ctest(1), older versions included, I have never found a
mention of the "--log_level" flag. Since the useful
"--output-on-failure" flag is already set, which will "[o]utput anything
outputted by the test program if the test should fail", I do not see any
further reason for more logging information.
This flag was introduced in 7665143afa,
but I have not found any reasoning for the flag in particular.
* check_ssl_cert: integrate new option to set maximum validity
check_ssl_cert has a new option with a new default: --maximum-validity. This change allows for services to use that option to override the default of 397 days. It is needed, if you have internal certificates that have a longer duration.
---------
Co-authored-by: Alexander A. Klimov <alexander.klimov@icinga.com>
Alexander A. Klimov
Julian Brost
Yonas Habteab
Alvar Penning
Pavel Motyrev
Christian Gut