CalcEventID's internal logic uses the TimestampToMilliseconds function
to convert the given eventTime to milliseconds. Within this function,
the timestamp is capped to prevent an overflow.
On three occasions, the input timestamp given to CalcEventID had already
been converted using TimestampToMilliseconds. The second
TimestampToMilliseconds function then checked the value and always
returned the capped maximum value. Consequently, CalcEventID returned
the same hash value for different timestamps.
This affected SendFlappingChange, SendAcknowledgementSet, and
SendAcknowledgementCleared. For example, when two acknowledgments were
created for the same service, the calculated event_id representing the
history table row would be identical.
Fixes#10465
Since the types and states attributes are user configurable and allowed to change at
runtime, we need to update the actual filter bitsets whenever these attributes change.
Otherwise, the filter bitsets would be stale and not reflect their current state.
Since recently, rockylinux:9 failed with linker errors against bz2, lzma
and zstd. Installing the relevant devel packages fixed the builds.
For reasons, cmake has started to add the -lbz2, -llzma, and -lzstd
linker flags. Since Icinga 2 usually does not need those, the relevant
devel packages were not installed. This may be due to some other
transitively linked dependency.
> 2025-06-05T13:12:59.5866282Z : && /usr/lib64/ccache/c++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wsuggest-override -Wrange-loop-construct -g -pthread -Winvalid-pch -O2 -g -DNDEBUG -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--export-dynamic -rdynamic third-party/mmatch/CMakeFiles/mmatch.dir/mmatch.c.o third-party/socketpair/CMakeFiles/socketpair.dir/socketpair.c.o lib/base/CMakeFiles/base.dir/application-version.cpp.o lib/base/CMakeFiles/base.dir/journaldlogger.cpp.o lib/base/CMakeFiles/base.dir/base_unity.cpp.o third-party/execvpe/CMakeFiles/execvpe.dir/execvpe.c.o lib/config/CMakeFiles/config.dir/config_lexer.cc.o lib/config/CMakeFiles/config.dir/config_parser.cc.o lib/config/CMakeFiles/config.dir/config_unity.cpp.o lib/remote/CMakeFiles/remote.dir/remote_unity.cpp.o plugins/CMakeFiles/check_nscp_api.dir/check_nscp_api.cpp.o -o Bin/RelWithDebInfo/check_nscp_api -Wl,-rpath,:::::::::::::::::::::::: -ldl /usr/lib64/libboost_coroutine.so.1.75.0 /usr/lib64/libboost_context.so.1.75.0 /usr/lib64/libboost_date_time.so.1.75.0 /usr/lib64/libboost_filesystem.so.1.75.0 /usr/lib64/libboost_iostreams.so.1.75.0 /usr/lib64/libboost_thread.so.1.75.0 /usr/lib64/libboost_system.so.1.75.0 /usr/lib64/libboost_program_options.so.1.75.0 /usr/lib64/libboost_regex.so.1.75.0 /usr/lib64/libssl.so /usr/lib64/libcrypto.so -lsystemd /lib64/libedit.so -ltermcap /usr/lib64/libboost_chrono.so.1.75.0 -lbz2 -llzma -lz -lzstd -licudata -licui18n -licuuc && :
> 2025-06-05T13:12:59.5872347Z /usr/bin/ld: cannot find -lbz2
> 2025-06-05T13:12:59.5872577Z /usr/bin/ld: cannot find -llzma
> 2025-06-05T13:12:59.5872802Z /usr/bin/ld: cannot find -lzstd
> 2025-06-05T13:12:59.5873039Z collect2: error: ld returned 1 exit status
Hopefully, this issue may resolve itself in the near future, but for the
time being this satisfies our CI run on Rocky Linux 9.
No external user needs to manipulate the actual object dependency
graphs. This was maybe introduced for debugging purposes at that time
but if someone messes with this in prod - good luck with that. Oh, apart
from that it's broken :( and doesn't track parents as its implies but
children.
Not sure why it's introduced in the first place, maybe for debugging
purposes at the early stage of Icinga 2 dev but I failed to see an
actual useful use case for it that's worth its maintenance burden. So,
this commit dropped it entirely from the DSL language.
Boost `1.88.0` introduced a feature [^1] that makes use of the Windows API, but it
uses API functions that are only available with `PSAPI_VERSION >= 2` and
Windows VISTA only supports `PSAPI_VERSION == 1`. Actually, that new feature
can also be disabled by setting the `BOOST_STACKTRACE_DISABLE_OFFSET_ADDR_BASE`
macro, but since it seems to be a useful feature and isn't even disabled by default,
we can just drop it that ancient Windows version instead of disabling it.
[^1]: https://github.com/boostorg/stacktrace/pull/200
With this mutex, we can have deadlock in the following case:
1/ Thread A processes a /v1/actions/acknowledge-problem request and locks the checkable
2/ Thread B processes a /v1/actions/add-comment and enters first the ConfigItem::ActivateItems() method and locks the static mutex there and starts the just created comment object, which triggers the OnCommentAdded() event.
3/ Thread A wants to activate the just created ack comment as well but since the mutex is already locked by TB, it blocks.
4/ Thread B's OnCommentAdded() even dispatch causes the IcingaDB::CommentAddedHandler() to be called and implicitly triggers full state update for the checkable. Now, the state serialization of that checkable (remember that's the same checkable currently locked by TA) also includes computing its severity, thus it calls either service->GetSeverity() or host->GetSeverity(). However, since computing the checkable severity (as of now) requires acquiring the object lock, and boom - they deadlock each other.
