Hi,
On 5/14/09 3:43 AM, Gerhard Lausser wrote:
> i reported this bug in january
> http://archive.netbsd.se/?ml=nagios-dev ... &m=9671673
> http://archive.netbsd.se/?ml=nagios-dev ... &m=9671670
> Imo, the condition for the second unlink needs to be reversed.
I think I found the source of the problem.
In base/checks.c, delete_check_result_file() is called within
reap_check_results():
- From "/* service check */" at line 167 if it's a service checkresult
for an unknown service or
- From "/* host check */" at line 192 if it's a host checkresult for an
unknown service or
- at line 211 if it's processed normally.
However Nagios calls delete_check_result_file() in base/utils.c at line
2486 too in process_check_result_queue() which is itself called from
base/checks at line 149 in reap_check_results() BEFORE the first case I
mentioned.
So basically it does:
reap_check_results()
process_check_result_queue()
/* For each files in checkresult */
process_check_result_file()
add_check_result_to_list()
delete_check_result_file()
/* For each files in checkresult */
Service: handle_async_service_check_result()
Host: handle_async_host_check_result_3x
delete_check_result_file()
Since process_check_result_queue() has already loaded all checkresult
files in a list in memory (by calling add_check_result_to_list() in
process_check_result_file()), reap_check_results() shouldn't call
delete_check_result_file() at all.
Does it make any sense to you?
--
Mathieu
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]