[checkmk-commits] Check_MK Git: check_mk: Cleaned bugs and documentation

Module: check_mk Branch: master Commit: 33c4f6b025c59962a89788386fdd3b5fcf7e3ee7 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=33c4f6b025c599… Author: Mathias Kettner &lt;mk(a)mathias-kettner.de&gt; Date: Mon Aug 15 12:52:43 2011 +0200 Cleaned bugs and documentation --- .bugs/220 | 10 +++++++--- .bugs/311 | 13 +++++++++---- agents/check_mk_agent.linux | 5 +++-- 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/.bugs/220 b/.bugs/220 index ad0547b..69b6536 100644 --- a/.bugs/220 +++ b/.bugs/220 @@ -1,10 +1,11 @@ Title: BI does not detect infinite recursions correctly Component: core +State: wontfix +Class: bug +Date: 2011-02-28 15:48:05 Benefit: 1 -State: open Cost: 1 -Date: 2011-02-28 15:48:05 -Class: bug +Fun: 0 At the moment BI does not catch direct loops (an object pointing to itselfs) or indirect loops (some childs object points back to a parent object). @@ -12,3 +13,6 @@ At the moment BI does not catch direct loops (an object pointing to itselfs) or In the first case the python error message is OK but in the second case the python error message is not very clear. + +2011-08-15 12:45:47: changed state open -> wontfix +Same as bug #204 diff --git a/.bugs/311 b/.bugs/311 index e7faede..c18822b 100644 --- a/.bugs/311 +++ b/.bugs/311 @@ -6,9 +6,14 @@ Cost: 4 Date: 2011-07-18 15:42:34 Class: nastiness -there is a very nasty issue with the IPMI agent code - we -kills the initial build of the SDR cache there will be no point in re-doing the scan and IPMI will be disabled forever. -The problem is that many IPMI modules are not able to handle concurrent requests. If building the SDR cache takes longer than 55+ seconds then we gh chance that a new check_mk_agent call happens via inetd. This second call will cause an IPMI issue which will cause the SDR cache scan to fail. +there is a very nasty issue with the IPMI agent code - if we kill the initial build of the SDR +cache there will be no point in re-doing the scan and IPMI will be disabled forever. The problem +is that many IPMI modules are not able to handle concurrent requests. If building the SDR cache +takes longer than 55+ seconds then there is a chance that a new check_mk_agent call happens via +inetd. This second call will cause an IPMI issue which will cause the SDR cache scan to fail. From that time on, IPMI will be disabled / broken. -Very ugly issue, maybe xinetd can disable multiple runs of the same service (but this would mean staleness issues will stop the agent forever) +Very ugly issue, maybe xinetd can disable multiple runs of the same service (but this would +mean staleness issues will stop the agent forever) + +Or we implement a caching feature similar to that of <<<ipmitool>>>. diff --git a/agents/check_mk_agent.linux b/agents/check_mk_agent.linux index d11c237..e3bd113 100755 --- a/agents/check_mk_agent.linux +++ b/agents/check_mk_agent.linux @@ -187,10 +187,11 @@ if which ipmitool >/dev/null then echo '<<<ipmi>>>' IPMI_FILE=$MK_CONFDIR/ipmitool_sensors.cache - # Use cache file after 20 minutes + + # Do not use cache file after 20 minutes IPMI_MAXAGE=1200 - # Check if file exists and recent enough + # Check if file exists and is recent enough if [ -s $IPMI_FILE ] then NOW=$(date +%s)