Unable to capture dumps from containers based on sample images

[jander-msft]

Describe the Bug

Using diagnostic tooling to capture dumps from containers that are running the sample images fail with error message "Problem launching createdump (may not have execute permissions): execve(./createdump) FAILED No such file or directory"

Steps to Reproduce

Bug logged from customer: dotnet/dotnet-monitor#2932

Using dotnet-dump will have this issue too.

Other Information

This appears to have regressed when the samples were changed from Debian to Alpine and trimming was introduced: f55f6c8#diff-a4b03be896dbf59bfab94d8ecb7216f2f7fedd1ff7feb4ba17a8fee9e1b53dba

[mthalman]

@jander-msft - Can you take a look and determine what the underlying issue is?

[jander-msft]

@dotnet/dotnet-diag, do you know if there is a way to preserve the createdump executable when publish ing applications as single file executables? It seems this is either trimmed out or excluded automatically, which means we cannot capture dumps of single file applications.

[noahfalk]

@mikem8361

[hoyosjs]

Single file hasn't supported createdump based dumps yet. Createdump not existing in the published output is expected right now

[jander-msft]

Seems like dotnet/runtime#68676 is tracking this capability for .NET 8.

@mthalman, is there a need to have the samples to publish as single file? It's not obvious to me why taking the extra step to make the application single file in a container would have any benefit over just self-contained and trimmed.

[mthalman]

@mthalman, is there a need to have the samples to publish as single file? It's not obvious to me why taking the extra step to make the application single file in a container would have any benefit over just self-contained and trimmed.

I thought there was something about trimming that made single file publishing the better option but I could be wrong.

Adding @richlander for his take.

[jander-msft]

I think the main difference between single-file publishing and non-single-file publishing is that single-file will produce a self-extracting executable (which is easier to acquire) whereas non-single-file publishing will publish the files to output directory from which all files need to be copied. Trimming should work in both cases.

The other thought I had was that maybe single-file would reduce the image size because all of the runtime and application files are compressed into a single compression container. It seems that this is the case in absolute terms:

• Single-file Alpine x64 image: 82,374,842 bytes
• Non-single file Alpine x64 image: 84,768,125 bytes

The single file image is 2.8% smaller. I'm not sure if this is significant savings.

Assuming that demonstration of acquisition of a single file (which is technically not the case today since the app image is copying everything in the output directory, which includes pdbs, json files, and the wwwroot) of the produced application from the build stage to the app stage is not a prominent feature of the sample, then publishing as single-file is not necessary.

If the small size reduction is the most significant difference between single-file vs non-single-file in terms of capabilities or other measurable aspects that the samples are trying to achieve, I would like to posit that the sample images should remove single-file publishing in favor of preserving diagnostics capabilities (in this particular case, dump collection). When dotnet/runtime#68676 is completed, then the samples can add back the single-file publishing usage, barring any other regression of diagnostic capabilities.

[mthalman]

[Triage]

@jander-msft - Can you validate that the single file deployment is indeed the culprit here? There was a switch from Debian to Alpine so it'd be good to just ensure that's not a factor in this as well.

Assuming the single file deployment is the sole factor here, we need to address the fact that our guidance states that single-file deployment is the way to go for trimming scenarios and that doesn't align with the available tools (createdump) available for the container. It's just fundamentally incompatible.

To address this, we should update the sample Dockerfile to not enable single-file deployment.

[eerhardt]

There are 2 cases where PublishSingleFile helps:

1. The size on disk will generally be smaller. I can't remember exactly why, but maybe @vitek-karas or @sbomer know why. I thought it was due to the native code being linked into a single assembly, and thus a bunch of things can be trimmed out.
2. When PublishReadyToRun=true, the startup time will generally be faster due to PublishReadyToRunComposite getting defaulted to true. See Enable PublishReadyToRunComposite for R2R singlefile apps sdk#25963.

When I was experimenting with the different app settings in a very basic Minimal API ASP.NET Core app, here were the numbers I found:

Publish Type	Startup	Disk Size
PublishTrimmed	675 ms	26.4 MB
PublishTrimmed & PublishSingleFile	669 ms	19.3 MB
PublishTrimmed & PublishReadyToRun	370 ms	41.8 MB
PublishTrimmed & PublishReadyToRun & PublishSingleFile	272 ms	40.2 MB

cc @mangod9 @agocke

[agocke]

The size on disk will generally be smaller. I can't remember exactly why, but maybe @vitek-karas or @sbomer know why. I thought it was due to the native code being linked into a single assembly, and thus a bunch of things can be trimmed out.

That, but also the single file host doesn't include the DAC or DBI

[jander-msft]

[Triage]

@jander-msft - Can you validate that the single file deployment is indeed the culprit here? There was a switch from Debian to Alpine so it'd be good to just ensure that's not a factor in this as well.

Assuming the single file deployment is the sole factor here, we need to address the fact that our guidance states that single-file deployment is the way to go for trimming scenarios and that doesn't align with the available tools (createdump) available for the container. It's just fundamentally incompatible.

To address this, we should update the sample Dockerfile to not enable single-file deployment.

I've validated that I am able to capture dumps from the Alpine aspnetcore slim image with the changes that are made in #4534