Dotnet-docker: libuv not found under 2.0.0 runtime

[hach-que]

Steps to reproduce the issue

1. Use a Dockerfile like so, with a .NET Core 2.0.0 application packaged:

FROM microsoft/dotnet:2.0.0-runtime
WORKDIR /srv
ADD pkg /srv/
RUN chown www-data -R /srv && chmod -R u-w,go-rwx /srv
USER www-data
EXPOSE 5000
ENTRYPOINT ["dotnet", "HiveMP.dll"]

Expected behavior

libuv should be available and load properly in the 2.0.0-runtime image.

Actual behavior

System.AggregateException: One or more errors occurred. (Unable to load DLL 'libuv': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)) ---> System.DllNotFoundException: Unable to load DLL 'libuv': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_loop_size()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvLoopHandle.Init(Libuv uv)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.Start(Int32 count)
   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Start[TContext](IHttpApplication`1 application)
---> (Inner Exception #0) System.DllNotFoundException: Unable to load DLL 'libuv': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_loop_size()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvLoopHandle.Init(Libuv uv)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter)

Additional information (e.g. issue happens only occasionally)

N/A

Output of docker version

Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   8eab29e
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   8eab29e
 Built:
 OS/Arch:      linux/amd64

Output of docker info

Containers: 9
 Running: 3
 Paused: 0
 Stopped: 6
Images: 133
Server Version: 1.12.1
Storage Driver: btrfs
 Build Version: Btrfs v4.1.2+20151002
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: oci runc
Default Runtime: oci
Security Options: apparmor
Kernel Version: 4.1.31-30-default
Operating System: openSUSE Leap 42.1 (x86_64)
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 3.822 GiB
Name: linux-bbrc
ID: PDB6:2DDB:DDIM:7LZ7:RHC3:TQGX:I27H:HQVY:ZJ5Q:PJTI:6EUS:VY7S
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: hachque
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
WARNING: No kernel memory limit support
Insecure Registries:
 127.0.0.0/8

[hach-que]

I should add, this is during work to upgrade from .NET Core 1.1.2 to 2.0.0. We've changed the target frameworks on the source code and Dockerfile from 1.1.2 to 2.0.0, and this is the problem we're encountering.

We're building the application on an OpenSUSE 42 based server and copying the packaged application to Docker. This previously worked fine on 1.1.2 under the exact same environment.

I'm going to try using 2.0.0-runtime-jessie instead to see if that fixes the issue.

[hach-que]

Looks like switching to 2.0.0-runtime-jessie fixes the issue.

[alexanderczigler]

Thank you @hach-que !

[SebastianStehle]

Thank you @hach-que. Can you explain why?

[hach-que]

I have no idea, I didn't prepare the Docker images so I don't know why this library is missing in one of them.

[SebastianStehle]

What I don't understand is that libuv.so is part of the published code.

[SebastianStehle]

Can you reopen it? I think you found a workaround, but not a solution.

[MichaelSimons]

@SebastianStehle, @hach-que - Can you share a project that reproduces the issue? It is mentioned this occurs when upgrading from .NET Core 1.1.2 to 2.0.0. Did you upgrade the AspNetCore 1.1 packages to 2.0? I am wondering if this is the same issue described in https://github.com/aspnet/aspnet-docker/issues/261.

[SebastianStehle]

Here is my project: https://github.com/squidex/squidex

I have not upgraded AspNetCore yet

[MichaelSimons]

@SebastianStehle - I think aspnet/aspnet-docker#261 explains the issue you were seeing.

[SebastianStehle]

It describes what I should do, but not why...

[MichaelSimons]

@natemcmaster - Can you answer this?

[natemcmaster]

IIUC the problem is that you're trying to use ASP.NET Core 1.x packages on .NET Core 2.0, right? If so, this is not supported. Use the .NET Core 1.x runtime instead.

cc @davidfowl

[SebastianStehle]

I got the same answer 3 times now. It is okay to say "I don't know" or "takes too much time to explain". :D

But it works with "2.0.0-runtime-jessie" image, so everything is fine. The reason that I have not migrated aspnet is that some of the packages I depend on have been migrated to NetStandard2.0 (from .NET Framework) and some of the other packages have not migrated to aspnetcore2.0 ;)

[hach-que]

In our case, we upgraded our app to .NET Core 2.0 and ASP.NET Core 2.0 when encountering this issue. We weren't using 1.1 libraries at all. However, I can't share the app because it's a proprietary product.

[natemcmaster]

@SebastianStehle Can you clarify what your question is exactly? I must have misunderstood what you were hoping for.

[MichaelSimons]

@hach-que - Any possibility you can provide a simplified repro? It is going to be difficult to diagnose without one.

[hach-que]

@MichaelSimons I'm fine with using the 2.0.0-runtime-jessie image to resolve this issue. I only re-opened this issue at the request of @SebastianStehle.

[SebastianStehle]

@natemcmaster I was hoping for an explanation, why the 2.0.0-runtime-jessie image works. But everything works now, it would be just nice to understand it.

[natemcmaster]

@SebastianStehle I'm not completely sure. I'm unable to reproduce the error. Here's what I did to repro:

FROM microsoft/dotnet:2.0.0-sdk AS builder
WORKDIR /app
RUN dotnet new web && dotnet publish -c Release -o /pub -p:PublishWithAspNetCoreTargetManifest=false

FROM microsoft/dotnet:2.0.0-runtime
WORKDIR /svr
COPY --from=BUILDER /pub /svr
ENV ASPNETCORE_URLS http://+:80
ENTRYPOINT ["dotnet", "app.dll"]

docker build --pull -t test ./
docker run --rm -it -p 5000:80 test

This builds and runs a server just fine, no libuv error.

One possibility (just guessing) is that your Docker host has a cached image for "microsoft/dotnet:2.0.0-runtime" that is actually contains 2.0.0-preview1 or 2.0.0-preview2 . docker build does not pull new base images by default; you have to run docker build --pull or docker pull explicitly. Switching tags to 2.0.0-runtime-jessie resulted in a cache-miss, so your host pulled a new image.

Another possibility is that there is a bug in the .NET Core SDK causing published output to trim libuv.so from the output when it should not. To verify that, I'd need to see the csproj file.

[MichaelSimons]

@SebastianStehle - Can you confirm you were using the latest 2.0-sdk image vs a preview copy? If using the latest could you share your csproj with @natemcmaster?

[MichaelSimons]

Cause of the original issue was explained. Secondary occurrence no longer reproduces. Closing issue. If there are additional questions or occurrences, feel free to log a new issue.

[mfdeveloper]

Thank you @hach-que ! This image version works for me. I've using microsoft/dotnet:2.1-sdk-alpine version, and seems be don't contains the libuv.so, I don't know why :sweat_smile:

The jessie is bigger than alpine, but it's ok!

PS: I'm don't using the microsoft/aspnetcore image, because I created the api using dotnet new webapi with dotnet-cli scaffold.

[mcm-ham]

@mfdeveloper That's a different issue that affects alpine, see https://github.com/aspnet/KestrelHttpServer/issues/2415. Note you can also workaround this issue by using sockets e.g

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
  WebHost.CreateDefaultBuilder(args)
    .UseSockets()
    .UseStartup<Startup>();