If the logger is started with `Activate()` before `SetActive()`, it won't
log anything, as the logger updates the "min severity" value of loggers
only when starting them, and if they're not active at that point, they
will just be ignored, so the min severity remains at info.
It also removes the extra `SendNextUpdate()` call from the
`NewCheckResultHandler` handler in Icinga DB, since it's subscribed to
the `NextCheckChanged` event anyway and that event is always emitted
before the `NewCheckResult` event gets triggered. This call became
redundant.
This commit introduces a new kinda special `OnRescheduleCheck` signal
that is emitted whenever we want to inform the checker to reschedule the
checkable at a specific timestamp without actually changing the next
check time. Previously, we called `SetNextCheck` with some random
timestamp just to enforce the checker to either pick it up immediately
or at a specific time. Then at some point in time, subscribing to the
`OnNextCheckChanged` signal became effectively unusable for any other
purpose than to inform the checker about a new next check time. Thus,
it resulted in introducing a new signal that is solely responsible for
informing the Icigna DB and IDO about a new next check time in places
where calling `SetNextCheck` did make sense. This commit does quite the
opposite: it replaces all calls to `SetNextCheck` that were only used to
inform the checker about a new next check time wit `OnRescheduleCheck`
calls. Only places where we actually wanted to change the next check time
still call `SetNextCheck` and thus inform the checker and all other listeners
about the new next check time. And as a bonus point, we now got rid of the
two object locks for child and parent at the same time.
Since the scheduler accounts for already running checks, we only need to
update the `next_check` timestamp in `Checkable::ExecuteCheck()` only
where it actually makes sense to do so, and as for local checks this
doesn't make sense at all. There only two cases where we need to update
the next check beforehand:
1) The execute command event is sent to a connected remote endpoint, so
we need to set the next check to a time in the future until we actually
receive the check result back from the remote endpoint. However, it must
not be too far in the future to avoid that the check is not re-run for
too long in case the remote endpoint never responds.
2) The check is a remote check, but either the endpoint is currently syncing
replay logs or not connected at all, and we are within the magical 5min
cold startup window. In these cases, the check is effectively skipped, and
there will be no check result for it coming in, we manually update the next
check normally as if the check was executed.
In the other cases, either the check is executed locally, which means the
`m_RunningCheck` flag already prevents the scheduler from re-running the check,
or this is a remote check and the endpoint is not connected, but we are outside
the cold startup window, in which case we also don't do anything as we've already
called `Checkable::ProcessCheckResult()` with an appropriate error state, which
in turn will call `Checkable::UpdateNextCheck()`.
This commit changes the ordering of CheckableScheduleInfo in the
multi-index container to ensure that checkables with running checks are
pushed to the end of the ordering. This prevents them from being
prioritized for scheduling ahead of others, which could lead to
unnecessary CPU load due to repeated scheduling attempts. By using a
very large value for the index of checkables with running checks, they
are effectively deprioritized until their current check is completed and
they can be reinserted with their actual next check time.
It's annoying to have to wait 10 seconds for the `liveness_disconnect`
test to complete, so make the timeout configurable and set it to a way
lower value to test the functionality.
There is no need to use our own option for this when an official
one exists. Even worse, on the current master, if we set ours to
on and the official one to OFF, the tests directory is included,
but the add_boost_test() command skips building/adding them, which
forces us to wrap additional calls to set_tests_properties() in
a check on the official option.
This adds a global fixture that can parse an additional argument to
the test executables (`--generate_ctest_config`). When run by
CMake during build, this generates a CTest script containing all
the tests and their properties.
An additional decorator, that defines CTest properties for a test case
or suite that will be added to the tests during config generation.
This version needs no hacks, no huge CMake scripts, just a bit of
additional C++ code that iterates over all test-cases and collects
the information CTest needs.
One caveat is still that this does not work with cross-compilation,
which probably isn't an issue to begin with, but there are also ways
to fix that if necessary.
It's going to be released tomorrow, so let's use the latest Debian release
as the base image while we are at it. Also run always `apt upgrade` to upgrade
any outdated packages (if any).
Previously, the https://github.com/Icinga/docker-icinga2 repository was
used to build the Docker images for Icinga 2. However, due to its
various design flaws, the resulted images had limited usability and
required a lot of manual tweaking to make something useful out of them.
This commit now follows our new principles of building Docker images
from the Icinga DB repository, and replaces the old separate repository
with this one. It makes use of the newest Docker BuildKit features to
build the images in a more efficient way, while also granting users full
flexibility to easily extend or modify the images as they see fit
without any issues.
This commit removes the -C parameter from the disk CheckCommand
since there is no possible way to use it in any functional capacity.
-C (or --clear) would reset the thresholds given previously
to allow for setting different thresholds for following filesystmes.
As an example:
check_disk -w 50% -c 5% -p / -C -w 1% -p /home
would only set the warning threshold for /home.
Since there is no way to use it reasonably with the Icinga 2
implementation of check_disk (since thresholds can only be
given once and the order is undefined), the clear flag
has no worth here.
My suggestion is to remove it avoid suggesting that it might
be used, but I left it as a comment in the ITL to prevent
the next person from "adding a missing parameter".
