> On 4. Apr 2018, at 21:03, Jude George <jude_geo...@symantec.com> wrote: > > If the system date/time is set forward by a few days, Icinga2 will > continue polling and we'll see the last-check-time and state of the > objects updated accordingly -- the timestamps will be at the new, future > time. However, if the system date/time is then restored (back) to its > original time, Icinga2 will stop updating its monitored objects. Perhaps > its "next check time" calculation gets confused because the > last-check-time of each object now appears to be in the future. > > However, I do notice that Icinga2 acknowledges the change in system date, > e.g.: > > [2017-12-01 17:06:00 +0000] information/Application: We jumped forward in > time: 604810 seconds > [2017-11-24 17:10:01 +0000] information/Application: We jumped backward in > time: 604734 seconds > > So it shouldn't be confused. Why does it stop polling? Is there any way > to make icinga2 continue polling after the system date has been set back? > I found that even restarting Icinga2 does not fix the problem. >
Scheduled check times are stored in the icinga2.state file, which can be deleted after stopping the daemon. Keep in mind that it stores other data too like acknowledgements. Another way would be to force a check via REST API and see how it goes. Cheers, Michael _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
