Previously, if you enable flapping for a Checkable but the corresponding
`Notification` object does not have `FlappingStart` or `FlappingEnd`
types set, the `no_more_notifications` flag wasn't reset to false again.
This commit ensures that this flag is always reset on `Recovery` even
the type filter does not match including when we miss the `Recovery` due
to Flapping state.
Since recently, the amazonlinux:2023 job in the Linux action fails due
to conflichting 'mariadb1*-devel' packages.
> package mariadb1011-devel-3:10.11.11-1.amzn2023.0.1.x86_64 from amazonlinux conflicts with mariadb105-devel provided by mariadb105-devel-3:10.5.16-1.amzn2023.0.7.x86_64 from amazonlinux
It seems like Amazon Linux added mariadb1011 packages next to mariadb105
packages, resulting in a conflict due to the wildcard. On prior runs,
the mariadb105 packages was installed.
This change installs mariadb-connector-c-devel instead of a specific
mariadb1*-devel package, as suggested by the package description.
Notification objects can refer User and Group objects similar to how they can
refer Host and Service objects, so that dependency feels quite natural. Note
that for evaluating most configuration, this order doesn't really matter, the
configuration will successfully evaluate in either case, the difference can be
noticed mainly in more advanced configurations, for example when dynamically
assigning user based on their groups. When accessing user objects from the
Notification object definition (like in the following example), without this
change, only groups configured directly in groups attribute of User objects are
visible and those added via assign clauses in UserGroup objects are missing.
With this commit, these are also visible.
apply Notification "n" to Host {
for (var u in get_objects(User)) {
log(u.name + " -> " + Json.encode(u.groups))
}
# [...]
}
The test was disabled due to a difference in behavior of mktime() between glibc
and musl. This inconsistency was fixed with the introduction of
Utility::NormalizeTm() and Alpine no longer needs this special case.
Ideally, Icinga 2 should behave consistenly across platforms. These special
cases only existed because mktime() on Windows behaved differently than the
implementation in glibc. With the introduction of Utility::NormalizeTm(),
there's now consistent behavior and the other expected results for windows are
no longer necessary (ideally, they shouldn't have existed in the first place).
There are inputs to mktime() where the behavior is not specified and there's
also no single obviously correct behavior. In particular, this affects how
auto-detection of whether DST is in effect is done when tm_isdst = -1 is set
and the time specified does not exist at all or exists twice on that day.
If different implementations are used within an Icinga 2 cluster, that can lead
to inconsistent behavior because different nodes may interpret the same
TimePeriod differently.
This commit introduces a wrapper to mktime(), namely Utility::NormalizeTm()
that implements the behavior provided by glibc. The choice for glibc's behavior
is pretty arbitrary, it was simply picked because most systems that are
officially/fully supported use it (with the only exception being Windows), so
this should give the least possible amount of user-visible changes.
As part of this commit, the closely related helper function mktime_const() is
also moved to Utility::TmToTimestamp() and made a wrapper around the newly
introduced NormalizeTm().
We didn't really 'invent' unity builds, more like adopted them, since
this is a common practice.
Also added a reference to the actual CMake variable in question instead
of just alluding to it
You can only 'recognize' something you already know and 'another thing',
while not necessarily wrong does not seem right here when there isn't a
'first thing' to notice.
Reference the Check Result State Mapping table for the CheckResult state
field. This table covers both Service and Host states while the prior
documentation string only covered Services.
This change is useful since there are different kinds of states for
Hosts when using the Icinga 2 API. For one, there is a "normalized"
version of 0 for UP and 1 for DOWN. Then there is the exit code version
for 0/1 for UP and 2/3 for DOWN. Unfortunately, often this depends on
the context and sometimes even intermingles.
To make it obvious which kind of state one can expect for a CheckResult
object, I have linked to the already existing documentation section.
A second abort() is needed at the end of `SigAbrtHandler()` to trigger the SIG_DFL action (in this case the core dump).
Also since `AttachDebugger()` disables the ability to dump core, so
it gets reenabled after returning from it.
for (const T& needle : haystack) creates the illusion that haystack is a
container of T and we're just borrowing needle. In these cases that's not true.
f isn't used otherwise in the function, so if possible, it can just be moved into the lambda, avoiding a copy.
Co-authored-by: Alexander Aleksandrovič Klimov <alexander.klimov@icinga.com>
not just boost::coroutines::detail::forced_unwind.
This is needed because as of Boost 1.87, boost::asio::spawn() uses Fiber, not Coroutine v1.
https://github.com/boostorg/asio/commit/df973a85ed69f021
This is safe because every actual exception shall inherit from std::exception. Except forced_unwind and its Fiber equivalent, so that `catch(const std::exception&)` doesn't catch them and only them.
The timestamps used both in the CheckerComponent and Checkable debug
logs were printed in the scientific notation, making them effectively
useless.
> debug/CheckerComponent: Scheduling info for checkable 'host!service' (2025-02-26 14:53:16 +0100): Object 'host!service', Next Check: 2025-02-26 14:53:16 +0100(1.74058e+09).
> debug/Checkable: Update checkable 'host!service' with check interval '300' from last check time at 2025-02-26 14:48:47 +0100 (1.74058e+09) to next check time at 2025-02-26 14:58:12 +0100 (1.74058e+09).
Switching to std::fixed actually shows the complete Unix timestamp.
> debug/CheckerComponent: Scheduling info for checkable 'host!service' (2025-02-26 15:36:44 +0000): Object 'host!service', Next Check: 2025-02-26 15:36:44 +0000 (1740584204).
> debug/Checkable: Update checkable 'host!service' with check interval '60' from last check time at 2025-02-26 15:37:11 +0000 (1740584232) to next check time at 2025-02-26 15:38:09 +0000 (1740584290).
