Desried state for schedule “xyz "was stopped . Last desired state was stopped. Actual state is running. about instance-scheduler-on-aws HOT 7 CLOSED

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 <[email protected]<mailto:[email protected]>> 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>.

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 <[email protected]<mailto:[email protected]>> 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>.