runtime: Failed to initialize CoreCLR, HRESULT: 0x80004005 when deploying on sandstorm

Moved from github.com/dotnet/cli/issues/4111 on behalf of @pgrm

Steps to reproduce

Install vagrant-spk
clone the sample repository pgrm/sandstorm-asp-net-core-test
inside the repository run
```
vagrant-spk vm up
vagrant-spk dev
```
open the browser and go to http://local.sandstorm.io:6080/
sign in with sample developer account (I always use alice)
go to http://local.sandstorm.io:6080/apps and click on example app
create a new instance
open the debug log (in the top an icon which looks like a terminal - it’s located between the trash bin and download arrow icons)

Expected behavior

At least it would be great if I could see the current dotnet version. Actually the yeoman generator default website should show up, but at least in the debug log, I should be able to see the dotnet version

Actual behavior

...** SANDSTORM SUPERVISOR: Starting up grain.
dotnet --version
Failed to initialize CoreCLR, HRESULT: 0x80004005

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     debian
 OS Version:  8
 OS Platform: Linux
 RID:         debian.8-x64

However, this dotnet --info was executed inside the .sandstorm/build.sh script where dotnet works just fine, and not inside .sandstorm/launcher.sh script where the problems show up.

I think the problem is, because sandstorm containers don’t have access to /proc/self/exe which was introduced with https://github.com/dotnet/coreclr/issues/1774. I tried to fake that file as discussed in https://github.com/sandstorm-io/sandstorm/issues/1582. I’ve set the link to point to /usr/local/bin/dotnet as well as /opt/dotnet/dotnet but in both cases I’m getting the same error.

Maybe I’m pointing it to the wrong file, or there is something more missing to make it work. Unfortunately the error message is hard to understand so some help would really be appreciated. Thx

About this issue

Original URL
State: open
Created 8 years ago
Comments: 42 (20 by maintainers)

Commits related to this issue

#2534 Fix: "ArgumentFormatter doesn't pretty-print rank-1 variable-bound arrays correctly" (#59) — committed to agocke/runtime by Jaswir a year ago

Most upvoted comments

I was going to close this issue, but I have found that /proc/self/exe is also explicitly used by libunwind to get the current executable path. The dl_iterate_phdr returns empty string in the dlpi_name and the libunwind needs to locate the executable then in order to read exception handling data from it. So we could update libunwind to try to use the getauxval(AT_EXECFN) and only fall back to the /proc/self/exe if it didn’t work.

janvorli on Nov 7, 2022

Getting rid of /proc/ would actually allow to run .NET self-contained executables to work within most of the shared hostings out there which provide SSH access.

Those are mostly running in some kind of chroot or similar reduced environments where access to /proc/ is not available.

pfeigl on Aug 25, 2020