Next Run is always in the past

[hayden.duncan]

Automaticloud version: 3.2.629.2004

I have a job scheduled to run every week day at 7:00 am. The server this software is installed on is currently 7/28/2016 9:35 AM and the job's next run time is 7/28/2016 7:00 AM. From what I have read, the local server's time should be used but if that's the case the job will never run because that time is always in the past.

Someone else set this software up a couple of days ago and I was expecting some EC2 instances to have started up automatically, since they have been scheduled to start each weekday. This job does not seem to run automatically because of those dates being out of sync. I have confirmed that the job does run manually and it starts the EC2 instances, however the "next run" date for the job remains the same.

[admin]

AutomatiClouds scheduler is using the time of the server where you installed it. It is not using the time of the EC2 instances you want to start,stop or backup. To be more precise: It is using the time and time zone of the local system account. You can check this be opening the background service log via the help menu:

Code: Select all

2016-07-28 18:35:41,699 [1] INFO Quartz.Server.QuartzServer - Scheduler started successfully. AutomatiCloudService Version: 2.0.134.1950
2016-07-28 18:35:41,700 [1] INFO Quartz.Server.QuartzServer - Running in time zone: W. Europe Daylight Time UTC-Offset: 02:00:00
2016-07-28 18:35:41,700 [1] INFO Quartz.Server.QuartzServer - Init License

Stephan

[hayden.duncan]

Yes, I understand that. That is what I meant by "The server this software is installed on is currently 7/28/2016 9:35 AM". The time of the server where the AutomaticClouds software is installed is ahead of the time that the 'Next Run' is set to.

So I've figured out the problem:
The timezone of the server, where the software is installed, had been updated after installing the AutomaticCloud server. The server's time was originally set to UTC +00:00 time. The Automaticloud software was then installed and the service started running.

Code: Select all

2016-07-26 06:21:31,370 [16] INFO Quartz.Core.QuartzScheduler - Scheduler QuartzScheduler_$_NON_CLUSTERED started.
2016-07-26 06:21:31,371 [16] INFO Quartz.Server.QuartzServer - Scheduler started successfully. AutomatiCloudService Version: 3.2.629.2004
2016-07-26 06:21:31,371 [16] INFO Quartz.Server.QuartzServer - Running in time zone: Coordinated Universal Time UTC-Offset: 00:00:00

The server's date/time was changed to UTC +10:00 timezone. Automaticloud still used the original timezone of UTC +00:00. Restarting the service seems to have fixed it for the moment.

After restarting the service:

Code: Select all

2016-07-29 08:55:41,984 [16] INFO Quartz.Core.QuartzScheduler - Scheduler QuartzScheduler_$_NON_CLUSTERED started.
2016-07-29 08:55:41,984 [16] INFO Quartz.Server.QuartzServer - Scheduler started successfully. AutomatiCloudService Version: 3.2.629.2004
2016-07-29 08:55:41,984 [16] INFO Quartz.Server.QuartzServer - Running in time zone: E. Australia Standard Time UTC-Offset: 10:00:00

It's a bit of an edge case and had I been the person to have set up the software initially then I probably would have pinpointed that to be the cause very quickly. It would be nice if the software raised a warning if the date/time used by the service doesn't match the local system's time.