1

I'm deploying a web application and various associated (continuous) webjobs to Azure using Visual Studio 2015. Until very recently my observation was that following the deployment process the webjobs would maintain their state; if the job was running, it would be restarted if the code was changed. If the job was Stopped, the code would update and the webjob would remain in the Stopped state.

The behavior I'm seeing now now is that the Stopped webjobs are starting following deployment. This is not the behavior I want, as the jobs are stopped for a reason. The fact that I'm publishing a new version of the web app code and/or webjob code shouldn't be seen as an assumption by the framework that the running state of the webjobs should be changed.

Is this behavior controllable?

Matthew
  • 947
  • 2
  • 13
  • 20

2 Answers2

2

Amit Apple gave a great response to this question here.

"To deploy a continuous WebJob in a stopped state simply add a file called disable.job at the root of your WebJob (binaries), this will tell the framework that the WebJob is currently stopped."

I did a quick search of the Kudu repo, and it looks like this is still valid. It isn't actually in the Kudu docs though.

Community
  • 1
  • 1
Rob Reagan
  • 7,313
  • 3
  • 20
  • 49
  • Ty. I had seen that also. The problem is that I want the webjob's running state to keep the same following deployment; if it's stopped, keep it stopped; if it's running, keep it running. I could have sworn this behavior (where the job is started if it's stopped) just started with me recently... – Matthew Feb 22 '17 at 02:03
1

From ContinuousJobRunner.cs of kudu project, we could find the IsDisabled property is used for checking whether the webjob is enable or not as follows:

private bool IsDisabled
{
    get { return OperationManager.Attempt(() => FileSystemHelpers.FileExists(_disableFilePath) || Settings.IsWebJobsStopped()); }
}

As I known, for continuous WebJobs, we have the following approaches to stop it.

1) Log into Azure Portal, under the "SETTINGS > Application settings" blade, add a new appsetting WEBJOBS_STOPPED and set value to 1

Note: This setting would disable both triggered webjobs and continuous webjobs.

2) Add a file named disable.job at the root of your WebJob binaries

You could log into Azure Portal, under the "SETTINGS > WebJobs" blade of your web app, choose your webjob and click "Stop". Also, you could manually add this file. For a programmatically way, you could leverage WebJobs API with basic auth using Deployment credentials of your web app to start/stop your WebJob.

The behavior I'm seeing now now is that the Stopped webjobs are starting following deployment. This is not the behavior I want, as the jobs are stopped for a reason.

For continuous WebJobs, I have tested this issue and found that the webjobs would maintain their state (stopped/running) after I published my web app or webjob. In summary, please check how do you stop your continuous WebJobs and you could create a new webjob to isolate this issue.

Bruce Chen
  • 18,207
  • 2
  • 21
  • 35
  • Thank you for your reply. Something not clear to me. You said, "For continuous WebJobs, I have tested this issue and found that the webjobs would maintain their state (stopped/running) after I published my web app or webjob. In summary, please check how do you stop your continuous WebJobs and you could create a new webjob to isolate this issue." Please clarify which configuration change(s) you made which allowed the webjobs to maintain their state after publishing. Or, are you saying that's the default behavior you experienced? – Matthew Mar 02 '17 at 17:17
  • 1
    I mean that if I stop/start my continuous WebJobs via the above approaches, then my WebJobs would maintain their state after publishing without changing any configuration. – Bruce Chen Mar 03 '17 at 01:30