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?
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.
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.
