Version: 7.6.0
Build: 26568

Immediately after a system reboot on Oct-13 (for Windows updates), every active job launched. The log messages look like this:


However, all of the jobs from Oct-12 appear to have run correctly based on logs generated by the scripts themselves.

How can I ensure that, after a system restart, VC does not kick off every job?

It is the property "Run missed Job" at Job->Main settings.

---

Thanks so much for the quick response here.

I worked my way through all the jobs and it, interestingly, they all already had that tick box (Main Settings -> Run missed job once at start) unchecked.

Is there anything else that could have caused this behavior?

Not that I see, but the log file for that day should tell what happened.

---

Heya Henrik -- interestingly enough the Windows box restarted for an update about a week ago (Nov-9) while at least one task was running, and when the machine came back online all VC tasks kicked off.

On investigation of the log (which is attached), it seems like a large period of records is missing.

There are observations on March-27, then they skip to Nov-9 at 03:26, which is when the machine booted back up. However, VC was running successfully throughout that period.

Based on what I can see from the log, it appears that VC is interpreting the outage as being almost 8 months long, and as a result is kicking off all jobs at once!

Is there a way to "flush" this large gap?

  vc-log-from-2016-11-09.xls (57kb) downloaded 48 time(s).

Machine restarts are definitely triggering this "launch all jobs" condition.

I just manually restarted the machine and a similar situation occurred, except this time the initial log dates started on Apr-4 and jumped to Nov-17.

The log file from today's by-hand restart is attached.

Thanks for your help!

  vc-log-from-2016-11-17.xls (44kb) downloaded 49 time(s).

Missed Jobs at start is one thing. But the problem in this case is that server time probably was wrong and was reset by system. See this line:

Triggers will be recalculated due to time change in the system. (4/4/2016 9:45:40 AM - 11/17/2016 12:53:04 PM)

Even date and time as you can see. This causes VisualCron to run Jobs within this period.

---