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.
They're just useless, since a `CheckResult` handler is never going to be
called without a check result and a checkable can't exist without a
checkcommand.
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.
