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.
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.
