SqlConnection.Open() throws System.InvalidOperationException: Internal connection fatal error on alpine #81
Comments
|
Hi @hpbieker , just to clarify, what is your environment running your application? are you using Linux containers on windows? |
|
It is a application compiled using dotnet core 2.0.x on Windows, then I built a alpine image in a docker host running on Ubuntu 16.04 and ran it on the same docker host. So real Linux Docker. |
|
Hi @hpbieker . Could you please share the output of I was not able to run a sample application using either of the runtime-alpine docker images complaining that it requires a dotnet SDK to be installed. Using the published DLL files also gives me error saying While I am investigating on the runtime-alpine docker image, it would be useful to know your environment setting as well. Thanks. |
I see that my project includes a System.Data.SqlClient.dll with fileversion 4.6.25921.2: And this one (also version 4.6.25921.2): Which environmental settings would you like me to provide? |
|
Where you able to reproduce this? |
|
I am facing probably a similar issue, it was tested and proved working with microsoft/dotnet:2.1-sdk and microsoft/aspnetcore:2 image hosted on Alpine Linux. Today I moved to the new microsoft/dotnet:2.1-sdk-alpine and microsoft/dotnet:2.1-aspnetcore-runtime-alpine. I updated the .csproj file to target netcoreapp2.1 and changed the versions of packages to match the 2.1.0-rc1-final version. My docker version is Docker version 18.03.0-ce, build 53f9d007af hosted on Alpine Linux 3.7. The output of trying to run the application looks like this. |
|
Connection string is ok, double checked that.
But the outcome was the same. |
|
@hpbieker Thanks for providing the information. |
|
Hello @hpbieker @marcin-jedynski Running a sample connection inside an alpine-docker hosted on ubuntu VM: Result after performing following commands where I am building the project inside the docker: My csproj file looks like this: I ran the same test with the latest image of dotnet:2.1-sdk-alpine and it was successful again: However, when I tried to run based on the dotnet-docker samples as described here, in which I modified the samples/dotnetapp/dotnetapp/Program.cs file to try and connect to SQL Server, I got this error: This is the only way I could reproduce the issue. Could you maybe show us the steps in which you are trying to run your application and if it is the same way that I am getting the exception with? Thanks. |
|
I should also mention that the same code built using microsoft/dotnet:2.1-sdk and run inside microsoft/dotnet:2.1-aspnetcore-runtime on Linux Manjaro Docker host is running fine with no problems. So this looks like a problem with Alpine images combnied with Alpine Docker host. Alpine host is running with kernel My Dockerfile: Contents of .csproj: My nuget.config: Output of dotnet info in alpine-sdk: Output of version in aspnetcore-runtime-alpine: |
|
As a temporary workaround I managed to get it running by switching the runtime stage image from Dockerhub: It's built on top of regular The same application runs inside it without any problems. |
|
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)
[sql_connection_error_stacktrace.txt] |
|
I have the same problem. I installed the package icu-libs and set DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false Example It works for microsoft/dotnet:2.1-aspnetcore-runtime-alpine |
|
@LeoTorok I was able to repro using your sample docker file. And the suggestion made by @kihamo worked for me. 🎉 Can you test that as well? |
|
Excellent!, I will, but only next Tuesday ...
El vie., 22 jun. 2018 19:27, Afsaneh Rafighi <notifications@github.com>
escribió:
… @LeoTorok <https://github.com/LeoTorok> I was able to repro using your
sample docker file. And the suggestion made by @kihamo
<https://github.com/kihamo> worked for me. 🎉 Can you test that as well?
@marcin-jedynski <https://github.com/marcin-jedynski> Looking at your
Docker file I see you have added RUN ["apt-get", "install", "paxctl"]
Could you please also try @kihamo <https://github.com/kihamo> suggestion?
Thanks!
—
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-399518446>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFf0nCijk-Fr_wYM2AXMuPat3PeRl6jdks5t_SjugaJpZM4TXEBn>
.
|
|
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 Edit II: kihamo's fix works. Thank you sir! |
|
Closing this issue now per @kihamo 's suggestion. |
|
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>
.
|
|
@kihamo's workaround resolved the issue for us, too. I echo this ^ request to get the fix into the default image ASAP please |
|
Hi Team, We are using linux container on windows and below is our docker image file. Any help is highly appreciated, i know this is a know issue, but for me, it is new. |
|
@alexmg the milestone reflects that the issue was closed during the 3.0 work. If you look at comment history, it was closed, because it was confirmed to work fine on 2.1 images: https://github.com/dotnet/corefx/issues/29147#issuecomment-399375323 |
|
@karelz It was the I assumed the need to add |
|
Hmmm, looks like it should not have been closed. @afsanehr can you please comment and reopen (if applicable)? cc @David-Engel @keeratsingh What has to happen to get it fixed in the Docker images? Or is the workaround the only thing we will support? |
|
@karelz I had checked with dotnet:2.1-sdk-alpine version. I will confirm with @David-Engel and update you soon. |
|
@karelz I wonder if this should be taken up by this repo: https://github.com/dotnet/dotnet-docker |
|
Bug confirmed on CentOS 7.6 x64, .net Core 2.2 standalone deployment generated by the SDK downloaded on 2018-12-10. Workaround: it was sufficient to rebuild without globalization invariant mode. It ain't just Alpine; this is a general issue. |
|
@tarekgh can you suggest how I would detect invariant mode? I can see the code in Coreclr which sets it according to the docs but there doesn't seem to be a public method to check it, since it can be set in a number of ways I can't just check the environment variable. This problem isn't Linux specific, if you set invariant mode on windows it'll do the same thing. The problem is that SqlClient needs to be able to create encodings that match those used in the database collation and if it can't you're going to end up with the possibility of garbled data, I don't think it's safe to allow a connection in this situation. At the moment I think it's catching the default collation sqlenvchange on connection and throwing when it can't create the encoding it needs, It should be checked earlier but probably still in the Open(Async) call because that's where users will have written code to handle and report connection problems. |
|
The easiest way to detect the Invariant mode is simply calling some thing like: CultureInfo.GetCultureInfo("en-US").EnglishName.Contains("Invariant")In the Invariant mode this should return true. otherwise, it will return false. |
|
As recently announced in the .NET Blog, focus on new SqlClient features an improvements is moving to the new Microsoft.Data.SqlClient package. For this reason, we are moving this issue to the new repo at https://github.com/dotnet/SqlClient. We will still use https://github.com/dotnet/corefx to track issues on other providers like System.Data.Odbc and System.Data.OleDB, and general ADO.NET and .NET data access issues. |
|
We just encountered this issue and there seems to be no suitable workaround whatsoever. This issue has been up for over a year, it might be worth prioritizing it. Currently the official Alpine images are next to worthless. |
|
@bmarinov The workaround is to ensure the globalization libraries are installed on your OS since SqlClient depends on them for globalization support. You can do this in Docker by adding those libraries to your Docker image on top of the official .NET Core Alpine image: The first change we will make to SqlClient for this issue is to detect the absence of globalization support and throw a better error message indicating it is required and missing. We may later investigate if SqlClient can function safely in Globalization Invariant Mode and what changes may be required for it, but that is not a high priority. |
|
@David-Engel thanks for the information. The exception being more specific would greatly help in the future, that would be a quick win for these of us trying to narrow down the issue in a timely manner. On a side note: considering ASPNET Core + EF Core is basically the go-to backend stack, wouldn't it be advisable to change the ASPNET Alpine images to include these globalization libraries? I mean, services should own some data unless we are doing "microservices" by invoking remote functions. In case the increased image size is a problem, is alternative one with a separate tag would be another good option too. I know that's not a question for this repository/project, just looking for some feedback. The workaround in question, while not optimal, might work for the time being. I can understand why the issue is not high on the list. But this really is a problem for people like me working in a regulated industry. As I mentioned in my previous comment, we cannot simply add a line to our Dockerfile or build a new image manually and push it to our private registry. We are one of these organizations "doing DevOps" while having separate Ops teams. 😅 Anyway, just wanted to shed some light why the workaround might be far from optimal in many cases. |
@bmarinov That's up to the maintainers of the Docker images. We originally filed an issue with them and they said it was on purpose to minimize the container size. The globalization libraries are a very large size/network penalty for applications that don't need it. The workaround is not really a workaround. It's how they expect you to build your image if your application has a dependency on globalization support. They have documented how to enable globalization mode on top of the base image if you need it. |
|
We've updated the driver to throw appropriate exception for globalization invariant mode in GA Release 1.0.19239.1 - Release notes. Closing the issue. |
|
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 accord to earlier comment you can detect the invariant mode by calling If invariant is true, you will need to get the globalization library as mentioned above. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
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.
The text was updated successfully, but these errors were encountered: