Azure-functions-core-tools: Host is taking longer than expected and ServiceUnavailable

[jackmusick]

When attempting to run my function app (func host start --debug vscode), I get the following message after "Job host started":

"The host is taking longer than expected to start."

It appears it doesn't like running on port 7071, despite nothing on my system using that port. When specifying the port in local.settings.json or as an argument (port 7072), it works, but calling func run my-function -f datafile.json, I get:

"Error calling the functions host: ServiceUnavailable"

func run appears to launch a new window and does not respect my host settings for port 7072.

[ahmelsayed]

func run should respect the setting in local.settings.json but it won't necessarily know about ports being passed in as a command line argument.

The way it works is a bit complicated, but func run tries to discover if there is a job host running on your machine. The way it does that is first by looking at local.settings.json and trying to communicate with a server that's running on that port. If it fails it tries to ping default port 7071, then 7072, then 7073, and so on.
When it pings these end points it's actually expecting a successful response with more information about a job host running on these ports. If no one is running, it launches a new one.

so for you, can you try specifying the port in local.settings.json and then try func host start or func run <functionName> and they both should respect the port defined there.

[jackmusick]

So, that's what I'd expect as well. What actually happens is this:

1. Run func host start --debug vscode. I get back that the application is listening on http://localhost:7072.
2. Run func run <functionName>. I get back that the application is listening on http://localhost:7071, ignoring my local.settings.json.
3. A second window pops up saying Error calling the functions host: ServiceUnavailable.
4. Previously opened window in step 2 continues to say The host is taking longer than expected to start.

All of this was done as admin as func host start doesn't seem to want to run at all without that.

[ahmelsayed]

You are right, sorry about that I should have tried it first.
This is because of a recent change in the runtime where an id is no longer required in host.json. I used to use the id there to verify that the runtime instance func run is talking to is the same as runtime as the "current" folder. Since there is no id in host.json now, the logic that checks that is failing. I'll fix that.

btw, func host start should not require admin. it used to, but with 32d33d64e35551897675dffba65fc453cd7f9b02 it shouldn't any more. It'll still prompt you to run as admin to clean up bindings that might have been left over, but I'm hoping to get rid of all that complicated admin logic before rc or rtm. if you run netsh http show urlacl http://+:7071 what do you get?

[jackmusick]

It's funny you mention netsh say that because I just stumbled upon an error about something already being registered in http.sys. In researching, I found that netsh http show urlacl did present something already bound to 7071. After running netsh http delete urlacl url=http://+:7071/, I was able to run my functions as normal. Hopefully this helps someone else.

Thanks for all your help!