.NET Core 3 application cannot connect to database when deployed on a Docker image

[uncvrd]

I have a .Net Core 3.0 project that I've been trying to deploy to a docker container that cannot seem to connect to the database context ever since I upgraded from Core 2.2 to Core 3.0. I can run the project locally just fine, but when it's deployed to a Docker container, the app hangs at the first instance where I call my context, which happens to be in my main() method in my Program.cs:

    public static void Main(string[] args)
    {
        IHost host = CreateHostBuilder(args).Build();

        using (IServiceScope scope = host.Services.CreateScope())
        {
            IServiceProvider services = scope.ServiceProvider;

            try
            {
                VideoContext context = services.GetRequiredService<VideoContext>();
                // my project never makes it past the following line:
                context.Database.Migrate();
                SeedData.Initialize(services);
            }
            catch (Exception e)
            {
                Console.WriteLine("error");
                IErrorLogService logger = services.GetRequiredService<IErrorLogService>();
                logger.LogError(e);
            }
        }

        host.Run();
    }  

The app will hang indefinitely and never make it past the context.Database.Migrate() method. There isn't even a SQL Connection Timeout exception thrown, so it has to be something before it even tries to make the SQL connection. My docker container doesn't throw any errors either.

Here's my dockerfile:

FROM mcr.microsoft.com/dotnet/core/sdk:3.0.100 AS build-env
WORKDIR /app

# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore

# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0.0
WORKDIR /app
# Make sure this folder exists
RUN mkdir -p /app/PrivateAssets/Attachments
COPY --from=build-env /app/out .
COPY secrets.json /root/.microsoft/usersecrets/44EFF06F-8817-4BCE-9CD3-872D7E944C3D/secrets.json
EXPOSE 80
ENTRYPOINT ["dotnet", "JPLTube.dll"]

Any ideas as to why my app hangs indefinitely? Please let me know if there's any other files needed to debug. I figured the only thing necessary was the dockerfile because the whole project runs fine on my local machine. Thank you!

[sageikosa]

Similar problem. Seems like a thread wait is blocked on a semaphore from another (native?) thread that died perhaps. I had a call stack window open at one point, and by looking at my search history today:

• system.data.sqlclient.sni.sniTcpHandle.EnableSSL
• system.data.sqlclient.sni.sniproxy.enablessl
  were involved about midway between the basic open connection/pooling stuff and the basic socket stuff.

Using sdk:3.0-alpine and aspnet:3.0-alpine instead of the default "3.0-buster" (Debian) got me past that. SQL has some issues with the "globalization invariant mode" on alpine, but that's solvable with:
dotnet/SqlClient#220

[sageikosa]

    public static void Main(string[] args)
    {
        var _app = CreateHostBuilder(args).Build();
        using (var _connect = new SqlConnection(@"server=sqlserver;Database=test;User Id=test;integrated security=false;Password=test;Connection Timeout=10"))
        {
            _connect.Open();
            using (var _command = new SqlCommand(@"select * from test.test", _connect))
            {
                using (var _reader = _command.ExecuteReader())
                {
                    while (_reader.Read())
                    {
                        Debug.WriteLine(_reader.GetValue(0).ToString());
                    }
                }
            }

        }

            _app.Run();
    }

I put this in a generic/empty ASPNET CORE 3 harness (use the VS 2019 wizard) and added some stuff in Main to get a SqlConnection. This stripped down use case mimicked my initial encounter with this hanging connection issue, without me having migrated anything from CORE 2.2.

Put a breakpoint on the _connect.Open() line, run in Docker, see that you hit the breakpoint, step into, wait a bit, press the debugger break button, see you're still on the _connect.Open() line, then open the call stack window.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["DataCore3/DataCore3.csproj", "DataCore3/"]
RUN dotnet restore "DataCore3/DataCore3.csproj"
COPY . .
WORKDIR "/src/DataCore3"
RUN dotnet build "DataCore3.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "DataCore3.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DataCore3.dll"]

[alexsandro-xpt]

I have the same problem, I'm using mcr.microsoft.com/dotnet/core/aspnet:3.0.0-alpine image.
I got more question in dotnet/SqlClient#220

[mts57017]

same issue here as well. Any new developments on this?

[nxtx]

Same issue, though the interesting point is:

• I do NOT experience this issue when my project is built and started via VisualStudio;
• rather I do experience this issue when I call docker-compose up or docker-compose up --build from PowerShell.

[scalablecory]

@leecow @MichaelSimons any idea what's going on here?

[MichaelSimons]

@scalablecory - based on @sageikosa repro, I'd suggest moving to/getting the SQL client team involved. The issue I am aware of is dotnet/SqlClient#222 but I am unaware of that causing a hang.

[sep15ms]

@uncvrd we had the same issue and followed one of the answers in dotnet/SqlClient#222 and found a workaround. By adding these two lines to our dockerfile it successfully connected. Prior to adding these lines it was completely hanging on the sqlconnection .Open(). This seemed to be to a SQL 2014 instance specific issue for us as no issues with our SQL 2017 instances.

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

For example:

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS base
WORKDIR /app
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

[uncvrd]

@sep15ms we're currently running SQL 2017 so this probably won't fix things, but I'll report back after we try this in the office next week, thanks!

[sageikosa]

FYI: my SQL server was a SQL2016 instance; and I didn't try with other version instances.

[thrashard]

@sep15ms thanks for the workaround, it has solved the issue for our .NET Core 3 application running in a Docker container mcr.microsoft.com/dotnet/core/aspnet:3.0 connecting to a SQL Server 2014 instance.

[carlossanlop]

The issue seems to be resolved, thank you @MichaelSimons for pointing out the issue.
Closing. If anyone in this thread has additional questions, feel free to reopen or create a new issue.

[tushi0407]

I am also facing kind of similar problem.My code is also stuck on db context and if i try to see it in quick watch it just break the application.Any other suggestion on it ?

[it8090]

@uncvrd we had the same issue and followed one of the answers in dotnet/SqlClient#222 and found a workaround. By adding these two lines to our dockerfile it successfully connected. Prior to adding these lines it was completely hanging on the sqlconnection .Open(). This seemed to be to a SQL 2014 instance specific issue for us as no issues with our SQL 2017 instances.

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

For example:

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS base
WORKDIR /app
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

thanks.

[reggiepangilinan]

I still have the connection problem even with
mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic

and this command

RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

I am using a the standard aspnetcore3.1 image from the sample
https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/Dockerfile

Does anyone know what is the issue?
Btw I'm trying to connect my container to a remote azure sql instance.

And here is the exception I'm getting

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)

[Samprash]

I am facing the same issue. Has anyone got this resolved? Please help!

[uncvrd]

For those still dealing with this issue, we were able to overcome this problem by changing our image to Ubuntu Bionic.

[Krokador]

@uncvrd we had the same issue and followed one of the answers in dotnet/SqlClient#222 and found a workaround. By adding these two lines to our dockerfile it successfully connected. Prior to adding these lines it was completely hanging on the sqlconnection .Open(). This seemed to be to a SQL 2014 instance specific issue for us as no issues with our SQL 2017 instances.

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

For example:

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS base
WORKDIR /app
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

Thank you so, so much! I just spent the past 2 days running around in circles until I figured out that DbConnection.Open() was where the code was hanging (at first I thought i had certificate issues, ugh!). Using aspnet:3.1-buster-slim as base with a connection to SQL Server 2016, and the 2 lines fixed it!

[Arthus15]

Hello,
I was faceing this issue for 2 days and I was always getting the error: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server).
Finnally I was able to fix this issue ussing the following connection string:
"ConnectionString": "Server=YourDatabaseServerName;Database=DatabaseName;User=sa;Password=YourPassword"
Take into consideration that YourDatabaseServerName reffers the name that you set on you docker-compose file for your database container in case that you are using docker compose to deploy the database also.

I hope you find this information usefull, thanks!