Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #8976] DB IDO: notification_id for contact notifications is out of range #2866

Closed
icinga-migration opened this issue Apr 2, 2015 · 12 comments
Labels
area/db-ido Database output blocker Blocks a release or needs immediate attention bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/8976

Created by minimoo on 2015-04-02 10:14:33 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2015-12-15 11:04:51 +00:00)
Target Version: 2.4.2
Last Update: 2016-02-23 09:58:15 +00:00 (in Redmine)

Icinga Version: 2.4.0
Backport?: Already backported
Include in Changelog: 1

[2015-04-02 11:10:39 GMT Summer Time] critical/IdoMysqlConnection: Error "Out of range value for column 'notification_id
' at row 1" when executing query "INSERT INTO icinga_contactnotifications (contact_object_id, end_time, end_time_usec, i
nstance_id, notification_id, start_time, start_time_usec) VALUES (63, FROM_UNIXTIME(1427969430), '927999', 1, -1, FROM_U
NIXTIME(1427969430), '927999')"

Attachments

Changesets

2015-12-15 10:59:06 +00:00 by mfriedrich 0239acc

Fix invalid notification_id in DB IDO query

fixes #8976

2016-02-23 08:13:02 +00:00 by mfriedrich 36c170d

Fix invalid notification_id in DB IDO query

fixes #8976

Relations:

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-04-02 10:19:24 +00:00

  • Status changed from New to Feedback
  • Assigned to set to minimoo

Please include information about how to reproduce this issue.

@icinga-migration
Copy link
Author

Updated by minimoo on 2015-04-02 10:34:47 +00:00

  • File added icinga2.state

Summary: icinga2.state should be rebuilt if database(state) has changed

Above crash in mysql is due to the icinga2.state file, and moving between backend engines. If I delete icinga2.state and let it be recreated, the above issue does not occur.

icinga2.state file attached.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-04-30 08:41:43 +00:00

  • Status changed from Feedback to New
  • Assigned to deleted minimoo

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-06-23 13:31:40 +00:00

  • Relates set to 9397

@icinga-migration
Copy link
Author

Updated by elimat on 2015-12-04 09:32:23 +00:00

I have a similar issue with version 2.4.1.

I have narrowed it down to a issue where the SQL that will do the insert to icinga2_contactnotifications use last_insert_id. When this is used it must be done in same same session as the previous insert without any other SQL statements in between. According to my debug log below there is a UPDATE statement between first INSERT and the second that failes and gets notification_id = "-1" (no id).

[2015-12-04 09:43:54 +0100] debug/IdoMysqlConnection: Query: INSERT INTO icinga_statehistory (check_source, current_check_attempt, endpoint_object_id, instance_id, last_hard_state, last_state, long_output, max_che
ck_attempts, object_id, output, state, state_change, state_time, state_time_usec, state_type) VALUES ('fnox-vm-prod-db001', '1', 1, 1, '1', '2', '', '5', 632, 'PROCS WARNING: 301 processes ', '1', '1', FROM_UNIXTI
ME (1449218634), '60817', '1')
[2015-12-04 09:43:54 +0100] debug/IdoMysqlConnection: Query: UPDATE icinga_servicestatus SET current_notification_number = '4', last_notification = FROM_UNIXTIME(1449218634), next_notification = FROM_UNIXTIME(14
49213119) WHERE instance_id = 1 AND service_object_id = 632
[2015-12-04 09:43:54 +0100] debug/IdoMysqlConnection: Query: INSERT INTO icinga_notifications (contacts_notified, end_time, end_time_usec, endpoint_object_id, escalated, instance_id, long_output, notification_reas
on, notification_type, object_id, output, start_time, start_time_usec, state) VALUES ('1', FROM_UNIXTIME(1449218634), '65308', 1, '0', 1, '', '0', '1', 632, 'PROCS WARNING: 301 processes ', FROM_UNIXTIME(144921863
4), '65308', '1')
[2015-12-04 09:43:54 +0100] debug/IdoMysqlConnection: Query: INSERT INTO icinga_contactnotifications (contact_object_id, end_time, end_time_usec, instance_id, notification_id, start_time, start_time_usec) VALUES (
193, FROM_UNIXTIME(1449218634), '65308', 1, -1, FROM_UNIXTIME(1449218634), '65308')

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-12-10 10:14:09 +00:00

  • Duplicated set to 10812

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-12-10 10:14:59 +00:00

  • Target Version set to Backlog

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-12-15 10:52:34 +00:00

  • Subject changed from mysql query error - notification_id out of range. to DB IDO: notification_id for contact notifications is out of range
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Priority changed from Normal to High
  • Target Version changed from Backlog to 2.4.2

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-12-15 10:54:03 +00:00

While tackling problems with IDO priority queue, we've also cleaned up the code and looked into dependant queries. We've found a few locations where the field was not returning and escaped string and was not enqueued properly. We'll push a fix for all these problems soon and backport that once tested successfully.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-12-15 10:54:35 +00:00

  • Relates set to 8714

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-12-15 11:04:51 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset 0239acc.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-02-23 09:58:15 +00:00

  • Backport? changed from Not yet backported to Already backported

@icinga-migration icinga-migration added blocker Blocks a release or needs immediate attention bug Something isn't working area/db-ido Database output labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.4.2 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/db-ido Database output blocker Blocks a release or needs immediate attention bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant