Why is my Azure WebJobs “settings.job” file being

When Azure WebJobs are stopped or restarted for whatever reason, there is a default grace period of 5 seconds before the host console process is terminated. Apparently it is possible to increase this time period by including a "settings.job" file with the WebJob when it is published to Azure, as explained here. Unfortunately I cannot get this to work for my website, and the shutdown period is always 5 seconds, despite this being a continuous WebJob that is published to a Basic App Service that is set to "Always On".

As per the sample code from the link, my Program.cs looks like this:

class Program
{
    static void Main()
    {
        var host = new JobHost();
        host.RunAndBlock();
    }
}

and my Functions.cs looks like this:

public class Functions
{
    public static async Task ProcessQueueMessageAsync(
        [QueueTrigger("testq")] string message, TextWriter log,
        CancellationToken cancellationToken)
    {
        Console.WriteLine("Function started.");
        try
        {
            await Task.Delay(TimeSpan.FromMinutes(10), cancellationToken);
        }
        catch (TaskCanceledException)
        {
            Shutdown().Wait();
        }
        Console.WriteLine("Function completed succesfully.");
    }

    private static async Task Shutdown()
    {
        Console.WriteLine("Function has been cancelled. Performing cleanup ...");
        await Task.Delay(TimeSpan.FromSeconds(30));
        Console.WriteLine("Function was cancelled and has terminated gracefully.");
    }
}

I have added a settings.job file to the project, and in its Properties in Visual Studio I have set it to "Copy always". The content of the file is as follows:

{ "stopping_wait_time": 60 }

The WebJob is published with the website. By using the Kudu tools and going to the debug console I can verify that the "settings.job" file is being copied across to the same location as the WebJob host executable:

However, if I look at the link https://xxx.scm.azurewebsites.net/api/continuouswebjobs the returned JSON does not include any settings at all:

{
    "status":"Stopped",
    "detailed_status":"f9e13c - Stopped\r\n",
    "log_url":"https://...",
    "name":"WebJobTest",
    "run_command":"WebJobTest.exe",
    "url":"https://...",
    "extra_info_url":"https://...",
    "type":"continuous",
    "error":null,
    "using_sdk":true,
    "settings":{
    }
}

Consequently, when I stop the WebJob from the Azure portal I end up with something like this in the logs:

[04/18/2016 12:53:12 > f9e13c: SYS INFO] Run script 'WebJobTest.exe' with script host - 'WindowsScriptHost'
[04/18/2016 12:53:12 > f9e13c: SYS INFO] Status changed to Running
[04/18/2016 12:53:13 > f9e13c: INFO] Found the following functions:
[04/18/2016 12:53:13 > f9e13c: INFO] WebJobTest.Functions.ProcessQueueMessageAsync
[04/18/2016 12:53:13 > f9e13c: INFO] Job host started
[04/18/2016 13:01:58 > f9e13c: INFO] Executing: 'Functions.ProcessQueueMessageAsync' - Reason: 'New queue message detected on 'testq'.'
[04/18/2016 13:01:58 > f9e13c: INFO] Function started.
[04/18/2016 13:02:47 > f9e13c: SYS INFO] Status changed to Disabling
[04/18/2016 13:02:53 > f9e13c: SYS INFO] Detected WebJob file/s were updated, refreshing WebJob
[04/18/2016 13:02:53 > f9e13c: SYS INFO] Status changed to Stopping
[04/18/2016 13:02:53 > f9e13c: INFO] Function has been cancelled. Performing cleanup ...
[04/18/2016 13:02:58 > f9e13c: ERR ] Thread was being aborted.
[04/18/2016 13:02:58 > f9e13c: SYS INFO] WebJob process was aborted
[04/18/2016 13:02:58 > f9e13c: SYS INFO] Status changed to Stopped

Note the standard 5 second gap between "Status changed to Stopping" and "Thread was being aborted".

Why is the "settings.job" file being ignored?

The problem is that your settings.job file has two sets of UTF-8 BOM, which is highly unusual and throws off the parser.

Specifically, it has the following sequence at the beginning (view using a hex editor): EF BB BF EF BB BF. Normally, the UTF-8 BOM is just EF BB BF.

What editor are you using that caused that?

In any case, once you fix that up, it should work fine.