[dev.icinga.com #2265] next_check attribute not updated after scheduling new check #847
Comments
Updated by mhein on 2012-01-20 10:48:43 +00:00
|
Updated by mhein on 2012-02-10 09:23:16 +00:00
|
Updated by jmosshammer on 2012-02-21 12:37:40 +00:00
@dnsmichi: We only read the next_check entry from the database, is it possible that the forced check isn't populated via idodb? |
Updated by mfriedrich on 2012-03-01 12:41:40 +00:00
i don't have time for that now, please attach a query how you fetch that data to help me investigate. |
Updated by jmosshammer on 2012-04-27 09:39:23 +00:00 That's rather minimalistic: SELECT WHERE s.config_type = '${retained_flag}' Since 1.7. all grid queries can be found in app/modules/Api/config/views/ |
Updated by mfriedrich on 2012-04-27 09:40:34 +00:00 jmosshammer wrote:
can you update the wiki guide for web testing in testing space with that information as well please? |
Updated by mfriedrich on 2012-04-30 12:49:10 +00:00 hmpf. that's still not a plain query but requires the joins to be explained into native sql. |
Updated by mfriedrich on 2012-04-30 13:09:19 +00:00
well for the algorithm itsself, passing a forced command to the pipe, sending an immediate void schedule_host_check(host *hst, time_t check_time, int options) { either taking the new event, or the existing one, setting the hst->next_check column there, this does not invoke a call to update the hoststatus itsself, and therefore not calling the broker functionality updating the neb module being registered in order to push data into the database. i'm not really convinced if that solution might work, as it does trigger another status update on the neb module, resulting in an insert/update query for the *status tables, but feel free to try that quick'n'dirty diff which should trigger the update after rescheduling a check. i won't apply that upstream without further feedback.
|
Updated by mfriedrich on 2012-09-24 12:38:36 +00:00
moving to core, since this requires a change on the core neb architecture. |
Updated by mfriedrich on 2012-09-24 12:39:37 +00:00
the provided fix should work as expected, and therefore be applied into the 1.8 dev tree. |
Updated by mfriedrich on 2012-09-24 12:39:51 +00:00
|
Updated by mfriedrich on 2012-09-24 13:19:58 +00:00
|
Updated by mfriedrich on 2012-09-24 14:40:25 +00:00
in master, for further test runs combined with icinga-web master. |
Updated by mfriedrich on 2012-09-28 16:01:05 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2265
Created by mopp on 2012-01-11 21:26:57 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2012-09-28 16:01:05 +00:00)
Target Version: 1.8
Last Update: 2012-09-28 16:01:05 +00:00 (in Redmine)
I realized a bug in the new web interface. It seems not to show the correct "next check" time.
Icinga: 1.6.1
To avoid any permissions problem I ran this command as root:
/var/spool/icinga/icinga.cmd
command_file=/var/spool/icinga/icinga.cmd
After executing the command above I waited a couple of seconds and check the "next check" on the new and classic interface.
Classic: 01-11-2012 22:23:45
New: 2012-01-11 22:24:56
If I wait until 22:23:45 the new web interface will show this time as "last check", so the icinga core works.
If I send the SCHEDULE_FORCED_SVC_CHECK again and run the command
Then the new web interface will show the correct "next check" time.
Changesets
2012-09-24 14:09:11 +00:00 by mfriedrich b3b89b2
Relations:
The text was updated successfully, but these errors were encountered: