locked
Timer Trigger stops running when I'm not watching it RRS feed

  • Question

  • I have a timer trigger which will run a few times while I have it open in the portal, then it goes to sleep.

    It's on an AppService plan and is AlwaysOn. It's running in US East. Here's a sample manual invocation:

    2019-02-07T16:50:56.988 [Information]

    (Reason='This function was programmatically called via the host APIs.', Id=ab978113-a39d-4bb5-a1c2-36b37b46c75e)

    It seems like after I manually invoke the function once, it will potentially run automatically a few more times, but then it stops. It then stays non-running for potentially weeks until I manually start it again.

    The CRON is  "schedule": "0 30 12-23 * * *", which I expect to run at the bottom of the hour from 12-23 UTC since I don't have the time set. The CRON doesn't seem to be the problem considering the above paragraph.

    As far as I can tell, I did everything right. The behavior distinctly resembles what I'd expect to happen if the AlwaysOn attribute was disabled, but it's enabled.


    Thursday, February 7, 2019 5:00 PM

Answers

  • It looks like you have Easy Auth (App Service Authentication) enabled. We currently have a bug on this being tracked here: https://github.com/Azure/azure-functions-host/issues/4048.

    Until it's fixed, the resolution is to either disable the Authentication and Authorization feature add a WEBSITE_WARMUP_PATH app setting and set it to the same relative URL that AlwaysOn is pinging (which is “/”). Easy Auth will ignore the request and let the Functions Host handle it, causing the function app to start correctly.


    Brett Samblanet -- Azure Functions

    • Proposed as answer by Mike Urnun (Azure)Microsoft employee Thursday, February 7, 2019 9:39 PM
    • Marked as answer by Zzbzq Friday, February 8, 2019 1:21 AM
    • Unmarked as answer by Zzbzq Friday, February 8, 2019 3:32 PM
    • Marked as answer by Zzbzq Monday, February 11, 2019 3:51 PM
    Thursday, February 7, 2019 8:06 PM

All replies

  • It looks like you have Easy Auth (App Service Authentication) enabled. We currently have a bug on this being tracked here: https://github.com/Azure/azure-functions-host/issues/4048.

    Until it's fixed, the resolution is to either disable the Authentication and Authorization feature add a WEBSITE_WARMUP_PATH app setting and set it to the same relative URL that AlwaysOn is pinging (which is “/”). Easy Auth will ignore the request and let the Functions Host handle it, causing the function app to start correctly.


    Brett Samblanet -- Azure Functions

    • Proposed as answer by Mike Urnun (Azure)Microsoft employee Thursday, February 7, 2019 9:39 PM
    • Marked as answer by Zzbzq Friday, February 8, 2019 1:21 AM
    • Unmarked as answer by Zzbzq Friday, February 8, 2019 3:32 PM
    • Marked as answer by Zzbzq Monday, February 11, 2019 3:51 PM
    Thursday, February 7, 2019 8:06 PM
  • I haven't tried it yet but it sounds really legit so I marked it as an answer.
    Friday, February 8, 2019 1:25 AM
  • Doesn't work though
    Friday, February 8, 2019 3:32 PM
  • Which approach did you take? Can you share exactly what you did?

    Brett Samblanet -- Azure Functions

    Friday, February 8, 2019 4:02 PM
  • I added WEBSITE_WARMUP_PATH of / to the app just using the Azure Portal. I clicked the Restart button on the function, manually invoked the function, then left the portal and waited until the next scheduled time, but it didn't run. It basically only runs on schedule if I keep the console open in the Azure portal after invoking it manually.
    Friday, February 8, 2019 5:15 PM
  • Which firings of your timer didn't work after you'd updated? I was able to find your app name based on the FunctionInovcationId above and I see firings today at 12:30 UTC -> 20:30 UTC, every hour on the :30 (and one extra invocation that looks like it was done via the portal at 14:17 UTC).

    How are you validating they're running (or they're not running)?


    Brett Samblanet -- Azure Functions

    Friday, February 8, 2019 9:44 PM
  • You're right. I was checking the logs in Kudu, but I guess those only get appended to when I'm logged in to the console. I was able to verify by checking logs of our other systems that it's working.
    Monday, February 11, 2019 3:51 PM