Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #2265] next_check attribute not updated after scheduling new check #847

Closed
icinga-migration opened this issue Jan 11, 2012 · 14 comments

Comments

@icinga-migration
Copy link

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)

Icinga Version: 1.6.1
OS Version: Any

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:

  1. grep icinga.cmd /usr/share/icinga-web/app/modules/Api/config/access.xml
    /var/spool/icinga/icinga.cmd
  2. grep icinga.cmd /etc/icinga/icinga.cfg
    command_file=/var/spool/icinga/icinga.cmd
  1. printf "[%lu] SCHEDULE_FORCED_SVC_CHECK;localhost;SSH;%lu\n" $(date +%s) $(date -d "2 minute"%s) > /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

  1. kill -1 $(pidof icinga)
    Then the new web interface will show the correct "next check" time.

Changesets

2012-09-24 14:09:11 +00:00 by mfriedrich b3b89b2

core: fix next_check attribute not updated after scheduling new check #2265 - MF

previously, we did not send an update to all neb modules after having
scheduled a check event - therefore next_check was not correctly updated
in idoutils/icinga-web. now doing so, an immediate update query will
follow once a check is scheduled.

refs #2265

Relations:

@icinga-migration
Copy link
Author

Updated by mhein on 2012-01-20 10:48:43 +00:00

  • Target Version set to 1.7

@icinga-migration
Copy link
Author

Updated by mhein on 2012-02-10 09:23:16 +00:00

  • Target Version changed from 1.7 to 1.6.2

@icinga-migration
Copy link
Author

Updated by jmosshammer on 2012-02-21 12:37:40 +00:00

  • Assigned to set to mfriedrich

@dnsmichi: We only read the next_check entry from the database, is it possible that the forced check isn't populated via idodb?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-03-01 12:41:40 +00:00

  • Target Version changed from 1.6.2 to 1.7

i don't have time for that now, please attach a query how you fetch that data to help me investigate.

@icinga-migration
Copy link
Author

Updated by jmosshammer on 2012-04-27 09:39:23 +00:00

That's rather minimalistic:

SELECT
s.icon_image AS SERVICE_ICON_IMAGE,
i.instance_name AS INSTANCE_NAME,
h.host_object_id AS HOST_OBJECT_ID,
s.service_object_id AS SERVICE_OBJECT_ID,
oh.name1 AS HOST_NAME,
h.alias AS HOST_ALIAS,
h.display_name AS HOST_DISPLAY_NAME,
os.name2 AS SERVICE_NAME,
s.display_name AS SERVICE_DISPLAY_NAME,
ss.process_performance_data AS SERVICE_PROCESS_PERFORMANCE_DATA,
ss.current_state AS SERVICE_CURRENT_STATE,
COALESCE (ss.last_state_change,ps.program_start_time) AS DURATION_START,
ps.program_start_time AS SERVICE_PROGRAM_START_TIME,
ss.last_check AS SERVICE_LAST_CHECK,
ss.next_check AS SERVICE_NEXT_CHECK,
ss.output AS SERVICE_OUTPUT,
ss.current_check_attempt AS SERVICE_CURRENT_CHECK_ATTEMPT,
ss.max_check_attempts AS service_max_attempt,
i.instance_id AS SERVICE_INSTANCE_ID,
s.service_id AS SERVICE_ID,
ss.notifications_enabled as notifications_enabled,
ss.problem_has_been_acknowledged as problem_acknowledged,
ss.scheduled_downtime_depth as scheduled_downtime_depth,
ss.has_been_checked as service_has_been_checked
FROM IcingaServices s
INNER JOIN s.instance i
INNER JOIN s.status ss
INNER JOIN s.host h
INNER JOIN h.object oh
INNER JOIN s.object os
INNER JOIN i.programstatus as ps

WHERE s.config_type = '${retained_flag}'

Since 1.7. all grid queries can be found in app/modules/Api/config/views/

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-27 09:40:34 +00:00

jmosshammer wrote:

Since 1.7. all grid queries can be found in app/modules/Api/config/views/

can you update the wiki guide for web testing in testing space with that information as well please?

@icinga-migration
Copy link
Author

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.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-30 13:09:19 +00:00

  • Status changed from New to Feedback
  • Target Version deleted 1.7

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.

diff --git a/base/checks.c b/base/checks.c
index eedecb7..d059b22 100644
--- a/base/checks.c
+++ b/base/checks.c
@@ -1985,6 +1985,9 @@ void schedule_service_check(service *svc, time_t check_time, int options) {
                log_debug_info(DEBUGL_CHECKS, 2, "Keeping original service check event (ignoring the new one).\n");
        }

+       /* update next_check time for service */
+       update_service_status(svc, FALSE);
+
        return;
 }

@@ -2463,6 +2466,9 @@ void schedule_host_check(host *hst, time_t check_time, int options) {
                log_debug_info(DEBUGL_CHECKS, 2, "Keeping original host check event (ignoring the new one).\n");
        }

+       /* update next_check time for host */
+       update_host_status(hst, FALSE);
+
        return;
 }

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-24 12:38:36 +00:00

  • Project changed from Web to Core, Classic UI, IDOUtils

moving to core, since this requires a change on the core neb architecture.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-24 12:39:37 +00:00

  • Category set to Check Scheduling
  • Status changed from Feedback to Assigned
  • Target Version set to 1.8
  • Icinga Version set to 1
  • OS Version set to Any

the provided fix should work as expected, and therefore be applied into the 1.8 dev tree.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-24 12:39:51 +00:00

  • Icinga Version changed from 1 to 1

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-24 13:19:58 +00:00

  • Subject changed from Web-Interface doesn't refresh "Next check" after SCHEDULE_FORCED_SVC_CHECK to next_check attribute not updated after scheduling new check

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-24 14:40:25 +00:00

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

in master, for further test runs combined with icinga-web master.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-28 16:01:05 +00:00

  • Status changed from 7 to Resolved

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant