[dev.icinga.com #2242] protect check_result_list with a mutex #838

icinga-migration opened this Issue Jan 4, 2012 · 5 comments


None yet
1 participant

icinga-migration commented Jan 4, 2012

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2242

Created by mfriedrich on 2012-01-04 10:04:10 +00:00

Assignee: mfriedrich
Status: Closed (closed on 2012-05-05 12:05:53 +00:00)
Target Version: (none)
Last Update: 2012-05-05 12:05:53 +00:00 (in Redmine)

protecting the check result lists in memory with a mutex ourselves we can make sure that modules could use the same mutex to gain exclusive access to that list.

at least DNX and mod_gearman use a special merge on that list before the reaping event happens, but this should be controlled by the core itsself.

especially when icinga-mq allows to pass check results via api, this will become mandatory to protect the core internal check result list.



icinga-migration commented Jan 27, 2012

Updated by mfriedrich on 2012-01-27 20:30:22 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mfriedrich

icinga-migration commented Feb 18, 2012

Updated by mfriedrich on 2012-02-18 12:25:25 +00:00

  • File added nagios-306-mutex-check_result_list.patch

found this elsewhere as well. seems to also affect the inner parts of the core itsself, not locking shared ressources properly.

add_check_result_to_list() and read_check_result() need mutex locking to prevent corruption of check_result_list.

Both the main and worker threads make calls to add_check_result_to_list but only the main thread calls read_check_result. However, both should acquire mutex locks for their modifications to the shared resource: check_result_list.



icinga-migration commented Feb 18, 2012

Updated by mfriedrich on 2012-02-18 14:33:49 +00:00

must be sort of an external addon in the above bug report, as this does not happen by default.
either way, such a lock would be nice to have when we implement -mq.


icinga-migration commented Mar 4, 2012

Updated by mfriedrich on 2012-03-04 12:27:31 +00:00

  • Status changed from Assigned to Feedback
  • Target Version deleted 1.7

icinga-migration commented May 5, 2012

Updated by mfriedrich on 2012-05-05 12:05:53 +00:00

  • Status changed from Feedback to Closed

no, locks which are not used, are worthless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment