[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


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.



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

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

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.



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.


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

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

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