cloudfoundry / dotnet-core-buildpack

Cloud Foundry buildpack for .NET Core on Linux
http://docs.cloudfoundry.org/buildpacks/
Apache License 2.0
91 stars 90 forks source link

Dotnet core prepublished application - ERR bash on process start #174

Closed roketworks closed 5 years ago

roketworks commented 6 years ago

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

api_version: 2.100.0
cf version 6.28.0+9e024bd.2017-06-27

What version of the buildpack you are using?

2.0.0

If you were attempting to accomplish a task, what was it you were attempting to do?

Push pre-published dotnet core application, with an assembly name containing at least 1 .

Sample .csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeFrameworkVersion>2.0.5</RuntimeFrameworkVersion>
    <AssemblyName>Something.WebApi</AssemblyName>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.3" />
  </ItemGroup>

</Project>

Steps to reproduce

  1. Create Blank dotnet core Web App
  2. Change AssemblyName to something containing at least 1 . (eg. Company.Test.WebApi)
  3. Publish application to folder
  4. In PublishOutput folder run cf push -b https://github.com/cloudfoundry/dotnet-core-buildpack.git

What did you expect to happen?

Application startup successfully

What was the actual behavior?

Application crashes trying to startup with bash error in logs:

[CELL/0] OUT Starting health monitoring of container
[APP/PROC/WEB/0] ERR bash: ./.: Is a directory
[APP/PROC/WEB/0] OUT Exit status 126
[CELL/SSHD/0] OUT Exit status 0
[API/0] OUT Process has crashed with type: "web"

Push output:

Creating container
Successfully created container
Downloading build artifacts cache...
Downloading app package...
Downloaded build artifacts cache (224B)
Downloaded app package (2.4M)
-----> Download go 1.9.1
-----> Running go build supply
-----> Dotnet-Core Buildpack version 2.0.0
-----> Installing libunwind 1.2.1
       Download [https://buildpacks.cloudfoundry.org/dependencies/manual-binaries/dotnet/libunwind-1.2.1-linux-x64-80af276a.tgz]
-----> Supplying Dotnet Core
-----> Installing dotnet 2.0.3
       Download [https://buildpacks.cloudfoundry.org/dependencies/dotnet/dotnet.2.0.3.linux-amd64-b56d13fc.tar.xz]
-----> Running go build finalize
-----> Finalizing Dotnet Core
       Required dotnetframework versions: [2.0.5]
       Download [https://buildpacks.cloudfoundry.org/dependencies/dotnet-framework/dotnet-framework.2.0.5.linux-amd64-62cc2fb0.tar.xz]
-----> Installing dotnet-framework 2.0.5
-----> Cleaning staging area
       Removing dotnet
Uploading droplet, build artifacts cache...
Exit status 0
Uploading build artifacts cache...
Uploading droplet...
Uploaded build artifacts cache (230B)
Uploaded droplet (3.4M)
Stopping instance d7becbfe-10cc-4e6a-b556-c04eba8f5437
Uploading complete
Destroying container
Successfully destroyed container

0 of 1 instances running, 1 crashed
FAILED
Error restarting application: Start unsuccessful

Running cf push -b https://github.com/cloudfoundry/dotnet-core-buildpack.git -v shows detected_start_command as cd . && ./. --server.urls http://0.0.0.0:${PORT}

Change AssemblyName in .csproj to remove any . will resolve the issue and the detected_start_command will be correct. Eg cd ${HOME} && dotnet ./WebApi.dll --server.urls http://0.0.0.0:${PORT}

I think this is due to using this line. With a prepublished application the project will be Something.WebApi.runtimeconfig.json and the strings.split() function will return only part of the file path.

I believe this would still happen with non-prepublished applications, but I have not tested that scenario.

Please confirm where necessary:

cf-gitbot commented 6 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/154537266

The labels on this github issue will be updated when the story is started.

bartstinson commented 6 years ago

When will the fix proposed be deployed? Thanks.

sclevine commented 6 years ago

Fixed in recent releases.

sclevine commented 6 years ago

Re-opened based on report of similar behavior in recent versions.

cf-gitbot commented 6 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/158675178

The labels on this github issue will be updated when the story is started.