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

[icinga-migration]

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.

Attachments

• nagios-306-mutex-check_result_list.patch mfriedrich - 2012-02-18 12:25:25 +00:00

[icinga-migration]

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]

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.

http://tracker.nagios.org/view.php?id=290

[icinga-migration]

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]

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]

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.