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.
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).
CMake 3.4 introduced a new policy [^1] which prevents from automatically
adding the compiler flags needed for exporting the symbols of the
executables and libraries without the `ENABLE_EXPORTS` property. So, by
defining this variable, CMake will restore the previous behaviour by
automatically adding the `ENABLE_EXPORTS` properties to all targets.
[1]: https://cmake.org/cmake/help/latest/policy/CMP0065.html
CMake version `< 3.5` is no longer supported, so the new CMake minimum
policy version is set to `3.8` to support C++17 unconditionally. After
checking all the policies that might affect Icinga 2 in any way, CMake
`3.17` is used as a max supported CMake policy. Anything above that may
work but we didn't explicitly verify the policies introduced with CMake
3.18 and later and may or may not affect Icinga 2.
The just merged Alpine CI run for LibreSSL from #9949 failed since it
missed the changes of the refactoring PR #10369. This change applied the
refactoring for Alpine as well, hopefully making the CI happy.
So far, Service::GetSeverity() only considered the state of its own host, i.e.
the implicit service to its own host dependency, and treated it similar to
acknowledgements and downtimes. In contrast, Host::GetSeverity() considered
reachability and treated it like a state, i.e. for the severity calculation,
the host was either up, down, or unreachable.
This commit changes the following things:
1. Make the service severity also consider explicitly configured dependencies
by using IsReachable().
2. Prefer acknowledgements and downtimes over unreachability in the severity
calculation so that if an already acknowledged or in-downtime services (i.e.
already handled service) becomes unreachable, it shouln't become more
severe.
3. To unify host and service severities a bit, hosts now use the same logic
that treats reachability more like acknowledgements/downtimes instead of
like a state (changing the other way around would the state from the check
plugin would not affect the severity for unrachable services anymore).
No change in functionality. The first two branches actually set the final
return value for the method, so they can just return directly, removing the
need to have the rest of the function inside an else block.
