Segmentation fault running new webapi project in Docker on Linux

[AnthonyMastrean]

Steps to reproduce the issue

1. Install SDK 2.1
2. Generate a new "webapi" project from the template

PS> dotnet new webapi --name Example --output .

3. Create the following Dockerfile

FROM microsoft/dotnet:2.1-sdk-alpine as build

WORKDIR /app

COPY . .

RUN dotnet restore
RUN dotnet publish

FROM microsoft/dotnet:2.1-aspnetcore-runtime-alpine

WORKDIR /app

COPY --from=build /app/bin/Debug/netcoreapp2.1/publish .

ENTRYPOINT ["dotnet", "Example.dll"]

4. Build the image

PS> docker build --tag example .

5. If you're on Windows, save the image, send it to a Linux environment, and load the image:

PS> docker save example:latest -o example.tar

$ docker load -i example.tar

6. Run the image (this exits; see the "actual behavior" section for a more robust command line)

$ docker run example
/app # dotnet Example.dll
Hosting environment: Production
Content root path: /app
Now listening on: http://[::]:5000
Application started. Press Ctrl+C to shut down.

Expected behavior

No segmentation fault! When I run the same image on my Windows host, where I built it, I get a properly running app.

PS> docker run example
Hosting environment: Production
Content root path: /app
Now listening on: http://[::]:80
Application started. Press Ctrl+C to shut down.

Actual behavior

To see the segfault printed, run the image interactively with a shell entrypoint and run the dotnet command manually.

$ docker run -it --entrypoint sh example
/app # dotnet Example.dll
Hosting environment: Production
Content root path: /app
Now listening on: http://[::]:5000
Application started. Press Ctrl+C to shut down.
Segmentation fault (core dumped)

If I try to build the same image on Linux I get the following:

$ docker build --pull --tag example .
Sending build context to Docker daemon  14.85kB
Step 1/9 : FROM microsoft/dotnet:2.1-sdk-alpine as build
2.1-sdk-alpine: Pulling from microsoft/dotnet
Digest: sha256:1377abcfbad651d86caacf49b6cf9622f1e881269d9aaa78f8224b9cffad42a6
Status: Image is up to date for microsoft/dotnet:2.1-sdk-alpine
 ---> 5fbf90294e33
Step 2/9 : WORKDIR /app
 ---> Using cache
 ---> cf264b655201
Step 3/9 : COPY . .
 ---> Using cache
 ---> db9f5b963962
Step 4/9 : RUN dotnet restore
 ---> Running in ba1d338050e4
Segmentation fault (core dumped)
The command '/bin/sh -c dotnet restore' returned a non-zero code: 139

Mitigation

If I build the same project, but using the stretch-slim based images, everything works fine.

FROM microsoft/dotnet:2.1-sdk as build

WORKDIR /app

COPY . .

RUN dotnet restore
RUN dotnet publish

FROM microsoft/dotnet:2.1-aspnetcore-runtime

WORKDIR /app

COPY --from=build /app/bin/Debug/netcoreapp2.1/publish .

ENTRYPOINT ["dotnet", "Example.dll"]

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

example.zip

Environment

$ cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

$ uname -a
Linux linux-test-env 3.10.0-862.2.3.el7.x86_64 #1 SMP Wed May 9 18:05:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Output of docker version

This is the output from my Linux environment.

Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:20:16 2018
 OS/Arch:      linux/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:23:58 2018
  OS/Arch:      linux/amd64
  Experimental: false

Output of docker info

This is the output from my Linux environment.

Containers: 87
 Running: 78
 Paused: 0
 Stopped: 9
Images: 74
Server Version: 18.03.1-ce
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-862.2.3.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 62.76GiB
Name: ng-devprom
ID: NSTE:OB5E:AVIJ:MJWU:A63C:QIB5:KHS4:32QR:7DDK:CIIS:5NPL:UONZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior.
         Reformat the filesystem with ftype=1 to enable d_type support.
         Running without d_type support will not be supported in future releases.

[MichaelSimons]

@AnthonyMastrean - Do you have SELinux enabled on your host? I suspect you are running into /~https://github.com/dotnet/coreclr/issues/17931.

[AnthonyMastrean]

SELinux is "enforcing"

$ cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

[AnthonyMastrean]

If I'm following, there's a fix and we're waiting on a port to 2.1?

/~https://github.com/dotnet/coreclr/issues/17931#issuecomment-388145709

[MichaelSimons]

Correct, it is scheduled to go into 2.1.1.

[MichaelSimons]

Closing as the underlying issue is being tracked with /~https://github.com/dotnet/coreclr/issues/17931