Weird behaviour during enable/disable jobs scheduling. #1941

philippevidal80 opened this Issue Jul 8, 2016 · 8 comments


None yet

4 participants



I installed Rundeck Cluster in 2.6.8-1 on 2 AWS EC2 instances (with S3 Logs, RDS).

Now, when I create or import a job with schedule that run for times and wish to make it not "schedule to run repeatedly" anymore, I select NO and SAVE the job definition.

Oddly, job continue to be schedule and run... ? Even if I choose NO EXECUTION and NO SCHEDULING after that.

The only solution found was to re-schedule the job with new cron and select YES for "schedule to run repeatedly", YES for "Enable Scheduling", YES for "Enable Execution" and SAVE job definition to reactivate the job "normaly".

Finally, let "schedule to run repeatedly" on YES and NO for "Enable Scheduling", NO for "Enable Execution". SAVE job definition and I could make this job definitively stop.

Did I missed something on "schedule/no schedule" process ? Is it a bug ?

I don't think this issue is related to cluster installation because all tasks have been done on the same rundeck server node.

Thank you.


@gschueler gschueler added the bug label Jul 8, 2016
makered commented Jul 8, 2016

Experiencing the exact same issue, also with a 2 node Rundeck cluster 2.6.8-1.

@gschueler gschueler added this to the 2.6.9 milestone Jul 8, 2016

I can't reproduce this.

You uploaded a scheduled job to a cluster node. On the same node you edited and selected "schedule to run repeatedly?" to NO, and saved it.

Is that all that you did?

makered commented Jul 13, 2016 edited

In my case, we have two nodes that are round-robin load-balanced so it is quite possible that we disabled the schedule on a job from a different node then the one where the job was initially scheduled (does it matter?).

Our workflow:

  1. Created a job and scheduled to run repeatedly.
  2. After some time and executions, edited the job in the UI, set "Scheduled to run repeatedly?" to "No" and saved.
  3. Noticed that job continued executing on the original schedule.

@makered thanks, i think the issue lies in the clustering

@gschueler gschueler self-assigned this Jul 13, 2016
@gschueler gschueler closed this in 21a0e4c Jul 14, 2016
makered commented Jul 15, 2016

Thanks @gschueler!


Big big thanks @gschueler.

Le 15 juil. 2016 21:08, "Ed Levin" a écrit :

Thanks @gschueler!

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1941 (comment),
or mute the thread


We are having the same issue - do you know when 2.6.9 will go up?


i set the due date to Aug 5, we expect to release it sometime this week however

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment