none
Can i prevent multiple instances of the same runbook from running concurrently? RRS feed

  • Question

  • Question is in the subject. I want to make sure that someone can't accidentally come along and kick off a runbook which is already running. Is that possible?
    Wednesday, August 27, 2014 10:14 AM

Answers

All replies

  • No this is not currently possible without coding up some logic yourself into the runbook. However, the runbook list view where you have to go to start or drill into a runbook does show the last job status, which this user could look at before starting another job for the runbook. If the status is "Running" it would mean a job is currently running for that runbook
    Wednesday, August 27, 2014 5:32 PM
  • Thanks Joe. Is it possible to get a status of all runbooks in a AA account via Powershell?
    Wednesday, August 27, 2014 8:02 PM
  • You can use Get-AzureAutomationJob to get all jobs for a certain runbook, and the output data should include a field for status (running, completed, etc) for each job.
    • Marked as answer by Jamie Thomson Thursday, August 28, 2014 7:02 AM
    Wednesday, August 27, 2014 9:42 PM
  • You can use Get-AzureAutomationJob to get all jobs for a certain runbook, and the output data should include a field for status (running, completed, etc) for each job.

    Excellent, thanks Joe.
    Thursday, August 28, 2014 7:02 AM
  • You can use Get-AzureAutomationJob to get all jobs for a certain runbook, and the output data should include a field for status (running, completed, etc) for each job.

    Hello again Joe,

    Yet another question, sorry :)

    I want to put some logic into my runbook that says "if I am already running, pause until I have stopped". I can call Get-AzureAutomationJob and filter on runbook name but of course that will always return at least one record because its this runbook that called get-AzureAutomationJob. Do you know of a way to get all job instances of a runbook except for the current instance?

    Essentially I need:

    get-azureautomationjob | where {$_.RunbookName -eq "<my runbook name>"} | where {$_.Id -ne <my Job ID>}

    [Hope that makes sense]

    Friday, August 29, 2014 8:10 AM
  • You can get both the job id and current runbook name for this job as described here. But you could also just subtract one running job from the total for this runbook, as you know one running job is this runbook, so when running jobs for this runbook equals 1, you know this is the only job for the runbook running.

    Note that you will run into issues if you tell a job to sleep and poll every once in a while to see if the other instances of the job have reached a terminal state. For example, if you have one job for this runbok running, and then another job for this runbook starts and waits for the first job to finish by sleeping and polling, and then a third job for this runbook start before the first one finishes, and also waits by sleeping and polling, you will end up with 2 jobs both constantly sleeping and polling waiting for each other to finish.

    Friday, August 29, 2014 6:25 PM
  • Yeah, I'm really not liking the thought of doing this I must be honest.

    Let's try another tack. Suppose I schedule a job to run every hour (you've said elsewhere that the ability to do that is coming), what would happen if the job takes longer than an hour to execute. Would the scheduler trigger the next execution or would the schedule say "Previous scheduled execution has not yet completed, wait until it has"?

    Monday, September 1, 2014 7:20 AM
  • It would trigger the next execution.
    Monday, September 1, 2014 7:17 PM
  • It would trigger the next execution.

    Ok, thanks. Guess I need a semaphore then. Boolean variable asset should do the job.
    Monday, September 1, 2014 7:53 PM
  • Technically since you have to get and set the value of a variable in 2 lines of code, the operation is not atomic, so its possible multiple jobs would try to set the value to true thinking it is false, if they ran those lines at the exact same time. Depending on your risk tolerance for another job running concurrently, you could do it that way though.

    One other alternative, if you did want this runbook job to run, but only after the current running job for this runbook was done would be to, if # jobs running > 1 for this runbook, schedule this runbook to run on a onetime schedule, at a random time between 5 – 10 minutes in the future, and then end this job. The current job would end, but the exact same logic would be applied 5 – 10 minutes later in the future, at which point either this job would run since it is now the only one running, or it would again schedule itself for the future, so on and so forth until it can run.


    Thursday, September 4, 2014 9:12 PM
  • Nice idea. I might even rework it slightly. I could just do away with the idea of creating a schedule ahead of time and just have the job, when it completes, create a one-time schedule for itself X hours into the future. The more I think about it the more I like that idea actually - for example I can use a variable asset to store X. Hmmm...

    Thanks for the replies Joe, especially useful when they cause you to think outside the box a little.



    Friday, September 5, 2014 7:51 AM
  • Nice idea. I might even rework it slightly. I could just do away with the idea of creating a schedule ahead of time and just have the job, when it completes, create a one-time schedule for itself X hours into the future. The more I think about it the more I like that idea actually - for example I can use a variable asset to store X. Hmmm...

    Have implemented this and it turns out there is a problem with it. my assets screen becomes littered with expired onetime schedules.

    Hence I've raised this feedback: Option to remove onetime schedule when completed

     


    Wednesday, October 1, 2014 11:02 AM
  • You can work around this by having the job of the runbook kicked off by the one time schedule delete the one time schedule when it starts. As a parameter to the runbook, take in the schedule name it was started on. When you set up the schedule to start the runbook on the schedule, pass the name of the schedule in as a parameter to the runbook. Then the job knows what schedule to delete to do a proper clean up.
    Thursday, October 2, 2014 8:03 PM
  • Hi Jamie,

    Just wanted to make you aware of this solution which someone on our team has published to solve this problem.

    There's also a sample runbook that uses it here.

    Friday, November 7, 2014 3:09 AM
  • Hi Jamie,

    Just wanted to make you aware of this solution which someone on our team has published to solve this problem.

    There's also a sample runbook that uses it here.

    Thanks Joe. Looks very useful, although still falls foul of the problem I mentioned here, I'm still having to hardcode the name of the Automation Account somewhere. I do still think we need built-in variables that return information about the execution environment (i.e. the Automation Account). See variables to provide execution context

    Definitely useful though, thank you.

    Friday, November 7, 2014 7:25 AM