SqlClient: SqlConnection.Open() throws System.InvalidOperationException: Internal connection fatal error on alpine

I get the error below when connecting to a SQL Server 2008R2 using the microsoft/dotnet:2.1.0-preview2-runtime-alpine docker image, but it works fine with microsoft/dotnet:2.1.0-preview2-runtime.

System.InvalidOperationException: Internal connection fatal error.
   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.Open()
[...my code..]
System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.Open()
[...my code..]
Boolean TryGetConnection(System.Data.Common.DbConnection, UInt32, Boolean, Boolean, System.Data.Common.DbConnectionOptions, System.Data.ProviderBase.DbConnectionInternal ByRef)

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 47 (15 by maintainers)

Commits related to this issue

Fix libs https://github.com/dotnet/corefx/issues/29147 — committed to imdocker/dotnet-core3 by imdocker 6 years ago
Merged PR 1627: Detect and throw Exception for Globalization Invariant Mode Addressing github issue 81: SqlConnection.Open() throws System.InvalidOperationException: Internal connection fatal error o... — committed to JRahnama/SqlClient by David-Engel 5 years ago

Most upvoted comments

I have the same problem. I installed the package icu-libs and set DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false

Example

RUN apk add --no-cache icu-libs
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false

It works for microsoft/dotnet:2.1-aspnetcore-runtime-alpine

+23

kihamo on Jun 22, 2018

@AfsanehR can you please look into how we can we make sure that:

Developers do not run into the problem by default.
If they run into it, the error message is descriptive enough to guide them to resolution (without further internet search, etc.).

karelz on Sep 4, 2018

@benmccallum accord to earlier comment you can detect the invariant mode by calling

CultureInfo.GetCultureInfo("en-US").EnglishName.Contains("Invariant")

If invariant is true, you will need to get the globalization library as mentioned above.

RUN apk add --no-cache icu-libs
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false

yukiwongky on Oct 23, 2019

To confirm, if upgrading to ASP.NET Core 3.0 and 3.0-alpine images, this issue is still present and the workaround needs to be applied? Doing an upgrade now and would be good to drop the size if possible.

benmccallum on Oct 17, 2019

@karelz It was the microsoft/dotnet:2.1-runtime-alpine image that I had to update with the following to resolve the issue.

RUN apk add --no-cache icu-libs
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false

I assumed the need to add icu-libs and set the DOTNET_SYSTEM_GLOBALIZATION_INVARIANT environment variable was a temporary workaround for the issue, and that future images would be updated to remove the need for this.

alexmg on Aug 28, 2018

@karelz yes, this is not a SqlClient issue. Either the base image of the docker file should be updated to have the icu-libs or the Dockerfile, for instance here , needs to have the following two lines suggested earlier.

RUN apk add --no-cache icu-libs
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false

AfsanehR-zz on Aug 28, 2018

As a temporary workaround I managed to get it running by switching the runtime stage image from microsoft/dotnet:2.1-aspnetcore-runtime-alpine to one of my creation.

Dockerhub: https://hub.docker.com/r/mjedynski/aspnetcore-paxmarked/ Source code: https://github.com/marcin-jedynski/aspnetcore-paxmarked

It’s built on top of regular microsoft/dotnet:2.1-aspnetcore-runtime and contains of modified by paxctl dotnet binary.

The same application runs inside it without any problems. @hpbieker @AfsanehR could you test your application running on my image ?

marcin-jedynski on May 12, 2018

@AfsanehR I too can confirm that @kihamo’s workaround resolved the issue. Based on the 3.0 milestone added by @karelz is it safe to assume that the image will be updated with the necessary changes in the future despite the issue being closed?

alexmg on Aug 9, 2018

I can confirm that the issue is resolved for us to. Sorry for the delay.

El mié., 27 jun. 2018 23:21, Afsaneh Rafighi notifications@github.com escribió:

Closing this issue now per @kihamo https://github.com/kihamo 's suggestion.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/corefx/issues/29147#issuecomment-400832970, or mute the thread https://github.com/notifications/unsubscribe-auth/AFf0nLEd2nteYkuLA6jwPhtcnt_UyJE2ks5uA_dugaJpZM4TXEBn .

LeoTorok on Jun 28, 2018

I am having the exact same problem running apps based on the 2.1-runtime-alpine image on a CoreOs Docker Host. I am willing to dig up all of the relevant info and share it, what exactly do you need?

Edit I: Here’s what I am using:

Docker version 18.03.1-ce, build 9ee9f40 Apps built using: 2.1-sdk-alpine Apps deployed using: 2.1.1-aspnetcore-runtime-alpine Apps running in docker on CoreOS, full version details below: NAME=“Container Linux by CoreOS” ID=coreos VERSION=1745.7.0 VERSION_ID=1745.7.0 BUILD_ID=2018-06-14-0909

Edit II: kihamo’s fix works. Thank you sir!

smk89 on Jun 22, 2018

We seem to be having this same issue connecting from an Alpine runtime image (from may 30th, the latest AFAIK) to a windows hosted SQL Server (actually to a listener in a high availability cluster if it makes any difference) The sql server version is

Microsoft SQL Server 2014 (SP2-CU11) (kb4077063) - 12.0.5579.x (x64) — Enterprise Edition (64-bit) on Windows NT <X64> (Build 9600:) (Hypervisor)

[sql_connection_error_stacktrace.txt] (https://github.com/dotnet/corefx/files/2076861/sql_connection_error_stacktrace.txt)

sql_connection_error_csproj.txt

sql_connection_error_dockerfile.txt

LeoTorok on Jun 6, 2018