Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #10075] Race condition in CreatePipeOverlapped #3370
This issue has been migrated from Redmine: https://dev.icinga.com/issues/10075
Created by Anonymous on 2015-09-01 16:16:57 +00:00
The error message on some checks does not make a lot of sense, it is meaningless.
I've tried to up the level of logging to debug, however it does not give more details, it reports starting the check, then the error message: Error: Unknown exception. I have seen this error since v2.3.4 that I can remember.
2016-08-08 10:51:20 +00:00 by (unknown) 1cd8a25
2016-08-10 10:12:56 +00:00 by gbeutner 37bd5ad
2016-08-11 07:48:01 +00:00 by gbeutner 132ee6c
Updated by mfriedrich on 2015-09-04 08:03:43 +00:00
Please attach the relevant config objects, e.g. service, host, checkcommand.
Is this a single instance setup, or are these checks running inside a cluster?
Updated by rafael.voss on 2016-07-05 15:23:07 +00:00
I have the same problem on my Windowsservers (2012 R2):
I have this problems with all Checks (default load, process etc.) and own Checks. The check suddenly goes to unknown but the next retrycheck is okay again.
The Checks are executed local on the Server. On Servers where the check is triggered from the satellite i don't have this problem.
Updated by BrandOuellette on 2016-07-13 05:32:24 +00:00
Same issue on Windows Server 2012 R2 Standard running Icinga Version 2.4.10
Returns "Exception occured while checking '...': Error: Unknown exception" periodically for any/all checks without running the actual service check command.
Please make this a priority to fix, as 'Unknown' Check Results fill up the event log.
Updated by TheFlyingCorpse on 2016-07-14 18:52:17 +00:00
Input, I went over my environment where I have this occuring on Icinga 2 agents ranging from 2.3.11, 2.4.3, 2.4.4 and 2.4.10. It ONLY happens with locally defined checks (the default ones). Any checks issued from upstream (master) does not have this issue.
Updated by gbeutner on 2016-08-08 09:58:21 +00:00
Looks like both exception_detail::get_boost_exception() as well as exception_detail::get_std_exception() returned NULL for the exception - which is unusual because all of our exceptions derive from both boost::exception and std::exception.
Updated by gbeutner on 2016-08-10 10:15:42 +00:00