Welcome to Azure Functions and App Services Blog!

Azure Functions is a serverless compute service from Microsoft Azure. With Azure Functions, you can easily create and deploy small pieces of code that are triggered by events such as HTTP requests, messages in queues, and timer schedules. This blog will cover various topics related to Azure Functions, including how to create, deploy, and manage functions, as well as best practices and use cases for this powerful cloud computing technology.

Showing posts with label webjobs. Show all posts

Unable to stop continuous webjobs

Issue:

· Why webjobs are not stopping? Tried stopping through,

o Portal

o Azure CLI

o REST API

o PowerShell

Analysis:

This is a common phenomenon and can happens with anyone. We wonder why are we not able to stop webjobs form portal or trough some other approach like azure CLI, REST API etc. while this was tired multiple times in past and it was working fine.

What happened suddenly? 🤔🤔

To understand the reason of this, we first must understand; what happens when we stop webjobs?

Let’s try it. 🤞🤞

To try this let’s create a web job under app service (web app) and then will try stopping it through portal and we'll see if it stops or not.

I just created a web app which doesn’t have any webjobs now.

Now created a continuous web job which is running successfully

It is very important to check the folder structure of webjobs in SCM aka KUDU site.

To do this, Open the SCM site and navigate to,

D:\home\site\wwwroot\App_Data\jobs\continuous/{webjobs name} path where continuous webjobs is deployed.

Only 2 files are there (.exe and .config).

And now let’s click on stop and see the result.

Webjobs stopped successfully.

Now let's observe what happened to folder structure in SCM site.

Just observe the difference in number of files before stopping and after stopping the webjobs. Earlier it was 2 and not it is 3.

A new file has been introduced named “disable.job” after stopping the webjobs.

Few points about disable.job file-> This file disappears when we start the webjobs and will appear again when we stop the webjobs. That means,

Webjobs should have this file when it is stopped.
Webjobs will also stop even if you place this file manually in that folder.
Webjobs will start running when you delete this file from your webjobs folder

So, presence of this file is the reason why webjobs is in stopped condition.

Let’s try other approaches.

1. REST API

Ref: https://docs.microsoft.com/en-us/rest/api/appservice/webapps/stopcontinuouswebjob

Examples post request

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/continuouswebjobs/{webJobName}/stop?api-version=2019-08-01

When a post request was sent for stopping a webjobs through REST API a disable.job file is created (similar to what happened earlier) which means stopping through portal and through REST API does same thing i.e. create a disable.job file inside the D:\home\site\wwwroot\App_Data\jobs\continuous\{webobs name} folder.

2. Azure CLI

Let’s execute the CLI command to stop continuous webjobs.

Ref: https://docs.microsoft.com/en-us/cli/azure/webapp/webjob/continuous?view=azure-cli-latest

Example CLI command

az webapp webjob continuous stop --name MyWebApp --resource-group MyResourceGroup --webjob-name MyWebjob

This also resulted same behavior i.e. creating a disable.job file.

Result of analysis

Now picture is clear. Presence of Disable.job is the reason for stopping a webjobs.

This means, when you are trying to stop the webjobs and somehow due to some reason disable.job file is not being created; can be one reason for not able to stop the webjobs.

Now we can focus on scenarios which can cause this issue and one of the most common scenarios is WEBSITE_RUN_FROM_PACKAGE.

When it’s value is set to 1 your WWWROOT folder becomes read-only that means you can’t write any files in WWWROOT folder and disable.job file is written inside that folder only when we perform stop webjobs operation.

With the WEBSITE_RUN_FROM_PACKAGE app setting value of 1, the zip deployment APIs copy your package to the d:\home\data\SitePackages folder instead of extracting the files to d:\home\site\wwwroot

With WEBSITE_RUN_FROM_PACKAGE, if you go into your d:\home\site\wwwroot folder from Kudu Console, you will see all the files from your zip, but the whole folder will be read-only. This is the same view that your runtime will have.

Reference for WEBSITE_RUN_FROM_PACKAGE,

Above case is only valid when webjobs are deployed inside App_data folder e.g. {D:\home\site\wwwroot\App_Data\jobs\continuous} and have

WEBSITE_RUN_FROM_PACKAGE set to 1 but here we have one more surprise. 😎😎

App_data is not the only folder where you can deploy your webjobs. It was the only folder before introducing the WEBSITE_RUN_FROM_PACKAGE but with the WWWROOT read-only challenges, they have introduced a new location for your webjobs which is

“d:\home\site\jobs\”

Which is outside the WWWROOT folder and inside the site folder.

So now we have 2 scenarios for webjobs deployment,

those that are deployed with your Web App (under app_data folder)
those that are deployed separately from your Web App

The first kind of simple, as they will just be part of the zip file, along with the rest of the app. But for those that are deployed separately, things are trickier because they can't just be uploaded to d:\home\site\wwwroot\app_data\jobs\..., which is read-only.

To solve this, Webjobs can now also be deployed to d:\home\site\jobs\.... Jobs from both locations can exist in the same app.

Additional Information

Azure also provide a configuration setting which stops all currently running webjobs.

· WEBJOBS_STOPPED - Set this setting to 1 to disable running any job (will also stop all currently running jobs)

Adding this setting with value 1 doesn’t create a disable.job file as it stops all currently running webjobs and not belongs to single webjobs.

Be careful when you implement this option.

Kill webjobs exe

If issue is very urgent and you want to stop the webjobs then you can kill the webjobs exe but this should be the last option

Hope this helps.

WebJob cannot be added from portal if deployment from source control is configured

WebJob cannot be added from portal if deployment from source control is configured.

Issue:

· WebJob cannot be added from portal if deployment from source control is configured.

Solution:

Azure webjobs is very popular now a days. It is used to run background task what we used to do with window schedular and here we are discussing about a common phenomenon which can be faced by anyone while create webjobs from the portal.

You can check in below screen show what happens when I click on Add button for creating a new web job.

webjobs

WebJob cannot be added from portal if deployment from source control is configured.

This message is clear, and we can easily decode it. This message indicates that your app service has some source control configured for CI/CD e.g. GitHub, DevOps etc and you can validate this in the deployment center option of your app service; like in my case I have configured GitHub as source control which is preventing me to me add new webjobs.

Now we know why we are not able to add webjobs? Then how to solve this issue.

If you have basic knowledge of webjobs then you should know the location of webjobs folder after deployment.

There are various ways to access webjobs folders and few of them are,

SCM or KUDU site
FTP

The path for webjobs is,

Triggered web jobs:

d:\home\site\wwwroot\app_data\jobs\triggered\{job name}

Continuous webjobs:

d:\home\site\wwwroot\app_data\jobs\continuous\{job name}

Note: While if you have Website_Run_From_Package enable (which makes d:\home\site\wwwroo folder read-only) then webjobs path will be,

d:\home\site\jobs\

That means you can directly deploy a WebJob in that path and your webjobs will start appearing in the portal.

This action will work with both SCM/KIDU and FTP.

Important:

You must be feeling happy that you are able to create webjobs, but this is not the permanent solution. This is just to unblock you if you want to create webjobs on urgent basis.

The error message was there for some reason which means If you have source control configured with your application, the webjobs should be deployed as part of the source control integration as webjobs is the part of your webapp.

If you deployed webjobs separately and then you deploy your webapp from the source control with “Remove additional files at destination” option checked then your webjobs will be deleted as they are not available in your deployment package under source control and you will be in trouble.

The correct way to deploy your webjobs in this case is to integrate them with your webapp in source control so that they are also deployed along with your app service.

Hope this helps. Please let me know if you have any query in this regard.

Azure Webjobs are missing after deployment of App Service or web app

Webjobs are missing after deployment of App Service or web app

Issue:

· My web jobs are deleted after deployment.

· I am not able to see webjobs in the portal

· I am sure I haven’t deleted it

Solution:

This is very common scenario. Many users face this issue which is very critical sometimes as web job can be performing some critical business scenario.

One important point which everyone should know is, webjobs are deployed inside App_Data folder inside WWWROOT of your app service.

The complete path depends on type of webjobs.

Triggered webjobs path - WWWROOT\app_data\jobs\triggered\ {job name}

Continuous webjobs path- WWWROOT\app_data\jobs\continuous\ {job name}

You can see clearly that both webjobs are stored inside the app_data folder.

Now due to some reason if either App_Data folder is deleted during deployment or we publish web app with option “remove additional files at destination” while App_Data folder is not part of source code then it will delete existing App_Data Folder.

Here I am giving example for DevOps aka VSTS where we have 2 options,

· Remove additional files at destination

· Exclude files from the App_Data folder

You can check this in the official document also,

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=azure-devops#web-deploy