On Azure deployment, getting "Unable to bind to http://localhost:9410 on the IPv6 loopback interface."

[muratg]

From @kirk-marple on July 20, 2016 16:50

On the first time I deployed my .NET Core Web API to Azure, I noticed this in my logs.

Obviously just a warning, but it's binding to localhost while on Azure, which seemed a little odd, so I thought I'd ask about it.

From global.json:
"version": "1.0.0-preview2-003121"

And I'm using 'net452' frameworks.

  "Timestamp": "2016-07-20T16:42:54.8896127+00:00",
  "Level": "Warning",
  "MessageTemplate": "Unable to bind to http://localhost:9410 on the IPv6 loopback interface.",
  "Exception": "System.AggregateException: One or more errors occurred. ---> Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.Check(Int32 statusCode)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<>c.<StartAsync>b__6_0(Object state)\r\n   --- End of inner exception stack trace ---\r\n   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)\r\n   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.CreateServer(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Start[TContext](IHttpApplication`1 application)\r\n---> (Inner Exception #0) Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.Check(Int32 statusCode)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<>c.<StartAsync>b__6_0(Object state)<---\r\n",
  "Properties": {
    "SourceContext": "Microsoft.AspNetCore.Server.Kestrel",
    "MachineName": "RD000D3A124D8B",
    "ThreadId": 1
  }

Copied from original issue: aspnet/KestrelHttpServer#1001

[muratg]

From @davidfowl on July 20, 2016 17:7

To azure using what? Azure app service?

[muratg]

From @kirk-marple on July 20, 2016 17:9

Correct, yeah. Azure App Service. Freshly created a new App Service, and published from VS.

[muratg]

From @davidfowl on July 21, 2016 6:48

What does your Program.Main look like

[muratg]

From @vmykhaylovskiy on July 21, 2016 8:5

I'm getting the same warning message on Azure App service. I'm using 'net46' frameworks with 1.0.0-preview2-003121 sdk.

Here is what my Program.Main looks like.

    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();
            host.Run();
        }
    }

[muratg]

From @kirk-marple on July 21, 2016 15:12

Same here... just the default from the template.

    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }

[muratg]

From @davidfowl on July 21, 2016 15:58

Which default template? Are you saying, the default template for ASP.NET Core ( .NET Framework) with no changes doesn't work on azure websites?

[muratg]

From @kirk-marple on July 21, 2016 16:3

Using Templates/Visual C#/.NET Core/ASP.NET Core Web Application (.NET Core), and selecting Web API.

It's not that it doesn't work, the Web API runs fine on Azure, after publishing.

I just noticed that warning in the log data, and thought it may be an concern, even though it doesn't affect the functionality of the Web API.

[muratg]

From @davidfowl on July 21, 2016 16:5

Are you running .NET Core or .NET Framework? You mentioned that you were using net452. Why did you pick .NET Core if that's the case?

[muratg]

From @kirk-marple on July 21, 2016 16:14

Right now, using the .NET Core project.json model (see attached example), but running net452 framework. Started this project last year during early DNX days, and been focusing on net452 for a stable baseline before going back and migrating to .NET Core runtime. The new project model works great, so didn't want to have to redo everything if we went to .NET Core runtime in future.

We also publish packages from our .NET Core projects and use them in .csproj projects (like on Service Fabric) where needed. So that part works well today.

project.json.txt

[muratg]

From @halter73 on July 22, 2016 0:50

@kirk-marple Kestrel binding to localhost is expected since Azure App Services use IIS as a reverse proxy in front of Kestrel on the same "machine". IIS uses an available port (in this case 9410) to communicate to Kestrel.

All the way until RC2, we would only try to bind to the IPv4 loopback address (127.0.0.1) when binding to "localhost", so you likely wouldn't have seen this warning. Starting in 1.0.0, we try to bind to the IPv6 loopback address as well ([::1]). It seems that Azre App Services doesn't allow binding to ([::1]).

I think that it makes sense for UseIISIntegration to specify http://127.0.0.1:[port] so you don't see this warning, since it seems it uses IPv4 anyway. @Tratcher what do you think?

[Tratcher]

Open questions:

• Why does [::1] binding fail in Azure App Services?
• Why does ANCM prefer connecting to 127.0.0.1? [::1] has been the preferred loopback address since Vista.

We want to avoid binding to a different address than then one ANCM will try first or we'll incur a delay at the start of every connection.

[muratg]

@davidebbo Could you look into @Tratcher's question re [::1] binding on Antares?

[davidebbo]

Not sure, might be a sandbox thing. If you have a simple repro (using a repo), we can probably verify.

[muratg]

cc @mikeharder