Why is my Azure WebJobs "settings.job" file being ignored?

Question

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?

Answer 1

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.