Desried state for schedule “xyz "was stopped . Last desired state was stopped. Actual state is running.

[prateek121]

How can I avoid the scheduler seeing the last desired from stateTable ...
I see lots of instances being skipped either stopping/starting .

As well looks to me stateTable is not updated correctly. As I run the scheduler much before the actual schedule time so that it gets updated with right state for comparison.

[arieleeuw]

Please enable the detailed logging and the logstreams will tell exactly why instances are (not) started or stopped. The table does contain the last desired state and is only updated when the desired state is changed according to your schedule for that instance. It is used to allow manual starts and stops being respected by the scheduler. If the enforced flag is not set, we only start/stop the instances if the new desired state does not match the actual state. If you want to ignore the last desired state you can set the enfored flag on the schedule. The state table is for internal use by the scheduler only to apply its scheduler logic to the instances. We’ve tested this logic extensively and we have no open issues regarding the scheduling not working as designed. On 7 Nov 2018, at 20:35, prateek121 <notifications@github.com<mailto:notifications@github.com>> wrote: How can I avoid the scheduler seeing the last desired from stateTable ... I see lots of instances being skipped either stopping/starting . As well looks to me stateTable is not updated correctly. As I run the scheduler much before the actual schedule time so that it gets updated with right state for comparison. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#55>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACBie5U0IL5WXzhD5FI8gILH3CxcLc_6ks5us0P3gaJpZM4YTMAT>.

[prateek121]

Here's what I see in the logs where no action is taken to start the instance for few instances
.Im not sure where am I not getting it.

DEBUG : [running] Time 07:00:33 is within 07:00:00-23:30:00, returned state is running
DEBUG : Active period in schedule "ExtendedHoursX7": "startAt7AMstopAtMidnight"
DEBUG : Desired state for instance from schedule "ExtendedHoursX7" is running, last desired state was running, actual state is stopped

The above same happens in case of stopping the instances. Where it ignores taking action

[arieleeuw]

Can you check if the root volume is encrypted? If this is the case then you need to give the Scheduler Role permission for kms:Grant action for the kms key used to encrypt that volume. From the log I see that the last desired state from the table was running. The calculated state is running, that is why there is no action. Without the enforced flag the Scheduler will compare the last desired state from the table with the desired state from the current schedule and will only take action, and store the new value as last desired state, if they differ. If thing don't work as expected please: A) The if any encryption is used for the root volume the give the role the required permissions to the key as described in the latest version of the documentation B) if you made any changes to the state table delete the field for the Instance, or in your case you can set it to stopped as in the next iteration if the desired state is running it should start the instance. Normally don't make any changes to the state table Hope this helps Arie On 8 Nov 2018, at 01:50, prateek121 <notifications@github.com<mailto:notifications@github.com>> wrote: Here's what I see in the logs where no action is taken to start the instance for few instances .Im not sure where am I not getting it. DEBUG : [running] Time 07:00:33 is within 07:00:00-23:30:00, returned state is running DEBUG : Active period in schedule "ExtendedHoursX7": "startAt7AMstopAtMidnight" DEBUG : Desired state for instance from schedule "ExtendedHoursX7" is running, last desired state was running, actual state is stopped — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#55 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACBieztIALZkWyyU3YUsqEj4ARuZfj5oks5us438gaJpZM4YTMAT>.

[prateek121]

There's no encryption in root volumes.
Though I see the problem in only one of our accounts , rest works perfectly fine.
Right now,Ive deleted the item from stateTable to see the difference over the weekend and Monday.
Will update you...

[prateek121]

So far I havent seen issues with accounts post deleting the item from stateTable for that account.
Thanks a lot @arieleeuw .
What happens in case of spot-instance included in the list of instance-ids ? For instances it couldn't stop for whatever reason.

[arieleeuw]

If we don't see an instance anymore that we keep track off in the table we automatically remove in a cleanup action we automatically run twice a day.
This keeps the items in the table compact and the table maintenance free.

Good to hear things are working now, thanks for your effort and patience!

[shsenior]

Closing due to time elapsed since last correspondence. Please re-open this if you are still having an issue.