Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #4357] after sig 11 kill ido2db has no activity and stop icinga core #1297
This issue has been migrated from Redmine: https://dev.icinga.com/issues/4357
Created by volkerg on 2013-06-28 07:35:32 +00:00
ido2db reports the following in the debug log
stopping the ido2db with /etc/init.d/ido2db stop kills only one ido2db process, one keeps still alive, kill -1 PID stops it immediatly
hu Jun 27 17:06:17 2013 .714706 [001.2] [pid=5338] [tid=140296096589568] ido2db_db_escape_string oracle changed string ('win_service_restart')
Thu Jun 27 17:06:17 2013 .850584 [001.2] [pid=5338] [tid=140296096589568] OCIERROR - MSG ORA-01403: no data found
Thu Jun 27 17:06:17 2013 .850591 [001.2] [pid=5338] [tid=140296096589568] ido2db_query_insert_or_update_eventhandlerdata_add() end
2013-06-29 10:44:28 +00:00 by Tommi 82a87cd
2013-06-29 14:46:19 +00:00 by (unknown) 2ae8b74
Updated by Tommi on 2013-06-29 10:51:37 +00:00
first time analysis:
But this is not causing sig11, because function closed ok
reason for the two ORA- might be a wrong variable within the lob free section
fixed in changeset 82a87cd
# afterwards, there is new data, which is running into SEGV. there are 3 handle_client_input start lines, but only one input section line
# trimming task tries to use invalid statement handles
looks like the statements are cleaned after SIG11,but trimming process tries to reuse these already freed handles.
the last two points i currently dont know how to fix
Updated by mfriedrich on 2013-06-29 10:58:33 +00:00
Updated by Tommi on 2013-06-29 11:14:52 +00:00
i suspect the sig11 in start_input_data, because there is a start, but no end within the logs. free_input_memory writes its end task, so looks like the sig11 may only occur in the buffer allocation part. But cant see an error within this.
Updated by Tommi on 2013-06-29 12:12:58 +00:00
branch is moved as suggested. dont got the point its allowed now to write direct into fixes/features branches without using my prefix
trimming tries to use oci_statement_instances_delete_time prepared statement, which is deallocated in ido2db_db_disconnect called from id2db_terminate_threads in child_signal_handler
therefore trimming must fail if its using the same idi structure. it would be consequent to stop the trimming task in case of a child signal or connect seperately with its own connection and statement handlers. which way is the prefered one?
Updated by Tommi on 2013-09-15 07:23:31 +00:00
There is an open point, which came up along this issue. Trimming task tries to use a prepared handle, which has been already deinitialized by the signal handler of the main task. Maybe it's an option to defer the statement deinitializing after the trimming task is really terminated or give the trimming task its own handlers. But up to now i dont have any glue which is the right solution nor how to implement it.
Updated by Tommi on 2014-02-21 17:34:48 +00:00
looks like the already provided patch solves the situation in real. Maybe there is a potential problem with the order of statement termination for the threads. Anyway, this is hard to debug for me and it results only in a obsolete message.