Director Stage deployment fails in OpenVZ CentOS 7

Just verbose, not verboseErrors.

{ā€œdiagnostic_informationā€:ā€œError: getrandom\n\n\t(0) icinga2: icinga::ConfigPackageUtility::CreateStage(icinga::String const&, boost::intrusive_ptricinga::Dictionary const&) (+0x34) [0x99aad4]\n\t(1) icinga2: icinga::ConfigStagesHandler::HandlePost(boost::intrusive_ptricinga::ApiUser const&, boost::beast::http::message<true, boost::beast::http::basic_string_body<char, std::char_traits, std::allocator >, boost::beast::http::basic_fields<std::allocator > >&, boost::intrusive_ptricinga::Url const&, boost::beast::http::message<false, boost::beast::http::basic_string_body<char, std::char_traits, std::allocator >, boost::beast::http::basic_fields<std::allocator > >&, boost::intrusive_ptricinga::Dictionary const&) (+0x339) [0xbc6dc9]\n\t(2) icinga2: icinga::ConfigStagesHandler::HandleRequest(icinga::AsioTlsStream&, boost::intrusive_ptricinga::ApiUser const&, boost::beast::http::message<true, boost::beast::http::basic_string_body<char, std::char_traits, std::allocator >, boost::beast::http::basic_fields<std::allocator > >&, boost::intrusive_ptricinga::Url const&, boost::beast::http::message<false, boost::beast::http::basic_string_body<char, std::char_traits, std::allocator >, boost::beast::http::basic_fields<std::allocator > >&, boost::intrusive_ptricinga::Dictionary const&, boost::asio::basic_yield_context<boost::asio::executor_binder<void ()(), boost::asio::executor> >&, icinga::HttpServerConnection&) (+0x7a) [0xbc82aa]\n\t(3) icinga2: icinga::HttpHandler::ProcessRequest(icinga::AsioTlsStream&, boost::intrusive_ptricinga::ApiUser const&, boost::beast::http::message<true, boost::beast::http::basic_string_body<char, std::char_traits, std::allocator >, boost::beast::http::basic_fields<std::allocator > >&, boost::beast::http::message<false, boost::beast::http::basic_string_body<char, std::char_traits, std::allocator >, boost::beast::http::basic_fields<std::allocator > >&, boost::asio::basic_yield_context<boost::asio::executor_binder<void ()(), boost::asio::executor> >&, icinga::HttpServerConnection&) (+0x793) [0x9956a3]\n\t(4) icinga2: icinga::HttpServerConnection::ProcessMessages(boost::asio::basic_yield_context<boost::asio::executor_binder<void (*)(), boost::asio::executor> >) (+0x1ab4) [0xb49274]\n\t(5) /usr/lib64/icinga2/sbin/icinga2() [0xb4ad41]\n\t(6) libboost_context.so.1.69.0: make_fcontext (+0x2f) [0x7f26972dd18f]\n\nā€,ā€œerrorā€:500.0,ā€œstatusā€:ā€œStage creation failed.ā€}[root@mon [root@mon ~]#

smells like BOOST issue with openVZ https://github.com/ZencashOfficial/zen/issues/184

Just for my understanding: This is a CentOS 7 VM with our packages from packages.icinga.com running in OpenVZ? Or are the RPMs self built?

The issue sounds a bit like that, still wondering about the kinking here.

Centos 7 VM with your packages running on openvz host which is on centos6

Hm, ok. make_fcontext is used for stack allocation for Boost coroutines which are now used in Icingaā€˜s network stack in 2.11.

Seems the call to get_random internally cannot succeed due to limitations in the OpenVZ kernel. I donā€™t know much about OpenVZ, but it sounds complicated. Please comment on the linked GitHub issue and link to this problem here to raise awareness. I think we as Icinga cannot do much here unfortunately.

https://github.com/boostorg/uuid/issues/91 says that the compiled Kernel headers must match the syscalls in the Kernel. With Boost 1.69 from Epel, it compiles against a CentOS 7 Kernel while your host system is a CentOS 6 kernel. This seems to be the culprit here. Iā€™m not asking this since I know that this is likely not possible, but upgrading the host system to CentOS 7 is not possible?

Cheers,
Michael

Unfortunately not possible to update the host. I will be moving that VM to a physical centos server today and let you guys know

1 Like