Previously, the `command#timeout` which by default is `1m`, was used to reschedule
the just sent remote check. However, this results into a bunch of extra checks being
sent to the remote host, even though the first one is still running. That's because
if one want to override the default timeout of the command for a specific host/service,
one has to set the `checkable#check_timeout` attribute to the desired value. So, this
commit makes sure that the `checkable#check_timeout` attribute (if set) is used to
reschedule the remote check.
If CPack fails, it may write the actual errors to a dedicated log file:
EXEC : CPack error : Problem running WiX. Please check 'D:/a/icinga2/icinga2/Build/_CPack_Packages/win64/WIX/wix.log' for errors. [D:\a\icinga2\icinga2\Build\PACKAGE.vcxproj]
Show all `*.log` files as part of the job output so that it doesn't get lost.
Instead of IoEngine::YieldCurrentCoroutine(yc) until m_Queues.FutureResponseActions.empty(), async-wait a CV which is updated along with m_Queues.FutureResponseActions.
Previously, recovery and ACK notifications were not delivered to users
who weren't notified about the problem state while having a configured
`Problem` type filter. However, since the type filter can also be
configured on the `Notification` object level, this resulted to an
incorrect behaviour. This PR changes the existing logic so that the
recovery and ACK notifications gets dropped only if the `Problem` filter
is configured on both the `User` and `Notification` object levels.
Ensure that the counter unit of measurement, "c", is parsed correctly
for performance data values again.
A prior refactoring in 720a88c29a489cec91815af49755413202802d7a changed
the parsing logic, resulting in an incorrect behavior for counter units.
By passing the raw input into the l_CsUoMs map first, the "c" UoM is
removed. Moving the explicit counter check before passing the raw unit
into the map resolves this issue.
Fixes#9540.
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().
