Timer Trigger Stopped Working RRS feed

  • Question

  • I have a Function that is triggered by a timer. It had been running fine for a while but then I discovered that it had stopped running (or running consistently).

    The timer is set for every 5 minutes (0 */5 * * * *).

    The host log does show this:

    Unable to acquire Singleton lock (xxxxxxxxxxxxxxxxx/Host.Functions.GetTankReadings.Listener)

    I pushed through an update to the host.json file and after that it looks like a lock was acquired. The timer triggers are functioning again but I really need to know what is happening and how to prevent it.

    Wednesday, June 28, 2017 2:15 PM

All replies

  • I had to push more updates and when the host restarted I again got the 'Unable to acquire Singleton lock' on the timers. How do I work around this temporarily and how do i fix this permanently?
    Wednesday, June 28, 2017 2:58 PM
  • From what I read these locks should be able to be acquired by the even if they are not initially acquired but that does not seem to be happening.
    Wednesday, June 28, 2017 3:07 PM
  • Is at least one of your Timer Function instances working?  This is a verbose message that is being logged and is expected but Timer-Triggered Functions.  Kindly see,


    Wednesday, June 28, 2017 10:01 PM
  • Thanks, I did look at the links you sent.

    According to Insights, there is only one server (instance) running of my production Functions App so there should be no other instances for the timer leases to compete with. It seems to be that when I update something and continuous deployment restarts the application that the old version might not be releasing the lease or something like that.

    I do have a separate Functions App with the same code that serves as a 'staging' environment. It uses the same storage account but different table and queue names. Could it be competing with my production app? I ask, because I turned off my staging app and then did a restart on the production app and the production app got locks on all the timers and the timers ran as expected.

    • Edited by Clarity Andrew Thursday, June 29, 2017 6:12 AM Clarification
    Thursday, June 29, 2017 6:11 AM
  • Just noticed that my staging and production host.json files are identical which means they have the same value for 'id'. Is this correct? Or do I need to take host.json out of source control and give each one a different value?
    Thursday, June 29, 2017 6:46 AM
  • I just found this which seems to confirm my issue.

    I have the same host id and am using the same storage account.

    Thursday, June 29, 2017 6:50 AM
  • Ahh yes that is very likely explanation. My recommendation is you remove the ID from all of your host.json files. The ID will then default to a value derived from your slot, which will mean your staging and production never compete for timer locks.
    Saturday, July 1, 2017 12:02 AM