Am 14.12.2010 15:49, schrieb Ton Voon: > > On 14 Dec 2010, at 11:34, Markus Wernicke wrote: > >> Hi Ton, >> >> >> Am 14.12.2010 12:25, schrieb Ton Voon: >>> Hi Markus, >>> >>> On 14 Dec 2010, at 09:54, Markus Wernicke wrote: >>> >>>> Hi List, >>>> >>>> im receiving following import_runtime error since yesterday (no >>>> upgrade >>>> made or something): >>>> >>>> DBD::mysql::db do failed: Cannot add or update a child row: a foreign >>>> key constraint fails (`odw`.`downtime_host_history`, CONSTRAINT >>>> `downtime_host_history_nagios_object_id_fk` FOREIGN KEY >>>> (`nagios_object_id`) REFERENCES `hosts` (`nagios_object_id`)) [for >>>> Statement "INSERT INTO downtime_host_history >>>> (actual_start_datetime, actual_end_datetime, >>>> nagios_object_id, >>>> author_name, comment_data, entry_datetime, >>>> scheduled_start_datetime, >>>> scheduled_end_datetime, >>>> is_fixed, duration, was_cancelled, >>>> nagios_internal_downtime_id) >>>> VALUES >>>> (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)"] at >>>> /usr/local/nagios/bin/import_runtime line 492. >>>> >>>> Any ideas where to search, in order to solve the problem? :) >>> >>> The failure is due to the nagios_object_id being used is not in the >>> hosts table. >>> >>> I think this could occur if the following happens: >>> * you have created a host and reloaded >>> * the host is created in Nagios and starts running some checks >>> * you then set some downtime for the host >> Absolutely right. >>> * you then decide that the host should be removed and delete it >> Hmhm if i remember correctly, i just renamed the host. >>> >>> All the above happens within an hour. When the import_runtime process >>> invokes, the downtimes are then associated to a host which does not >>> exist and so the foreign key constraint of the nagios_object_id does >>> not exist either. >>> >>> If you can confirm if this is what happened, I'll look into a fix. I >>> think in these cases, the downtime should just be ignored and not >>> imported into ODW. >> Thanks! > > I've recreated this problem and this is the fix: > https://secure.opsera.com/wsvn/wsvn/opsview?op=comp&compare[]=...@5554&compare[]=...@5555 > > I used this opportunity to have regular ODW testing enabled (we had > the test scripts, but we didn't set them up to always run), so this > case will always be covered now.
Thanks Ton. But i have no permission to open that Link! _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/lists/listinfo/opsview-users
