Docker: 5.3.12 (dotnet core) hung

viceice

The host is a hyper-v virtual machine running on a dual socket amd opteron 6300 server with 256GB RAM. ~50% physical memory used.

Our prod proget server is running in k3s kubernetes v1.18.9+k3s1 (630bebf9). But i tested the simple docker command posted above, which fails too.

VM stats:

8 cores
16GB ram (no swapfile)
ubuntu 18.04.5 with linux-azure kernel 5.4.0-1025-azure
k3s v1.18.9+k3s1 (630bebf9)
docker-ce 19.03.13 (btrfs)

let me know if you need more specs.

viceice

We are also deprecating / migrating the sql server in near future.

So i can move the database to a linux docker sql server to check, if there are any changes.

Another thing is the proget database is pretty old. it was migrated since 2014-08-27 12:19:06.093.

rhessinger

Hi @viceice,

Nothing is sticking out to me that there is an issue. Your hardware looks fine (without knowing everything else running on the server/kube pods).

It looks like it is hanging when trying to load the current database schema version. The code for both mono and .net core does not differ for this component. Is there anything that is different from your progetmono and progetcore start scripts in kubernetes? I would put some enphasis around the networking piece in kubernetes.

Thanks,
Rich

viceice

No, I don't change anything. We are using the official docker image.
I can reproduce it even on a plain docker container, so kubernetes isn't the cause.
I can also reproduce it on a similar vm, where nothing else is running.

rhessinger

Hi @viceice,

I'm having trouble recreating this issue. I tested this by setting up a SQL Server 2014 instance with updates installed to bring it to version 12.0.6372.1. I have tried both the proget and the progetmono images at version 5.3.12. Both of them boot up and run all the scripts completely fine. I have even tested using your exact docker command and only changing out the SQL connection string. So far I cannot get it to hang. Is there anything else unique about your network configuration? Do you have just a standard install of SQL Server? Is there any proxy or VPN that requests are routed through to connect to your SQL Server?

Thanks,
Rich

viceice

SQL Server is installed on a Windows Server 2012 R2 Core vm. That is directly accessable via IPv4 and IPv6. Nothing special here.

I'll more a copy of the db to a single docker host and try running sql server and proget on same docker host.
I'll also test Connection Timeout=30 to my connection string, so i should get a timeout while trying to connect.

viceice

test on local docker host now and it works as expected, so it must be something with the old sql server

docker run --name proget-sql \
      -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=ProGetTest!1234' \
      -e 'MSSQL_PID=Express' -p 1433:1433 \
      -d mcr.microsoft.com/mssql/server:2019-latest

# restore db

docker run \
    -e SQL_CONNECTION_STRING='Data Source=docker-m01; Initial Catalog=Proget; User ID=sa; Password=ProGetTest!1234;Connection Timeout=10' \
    -e Logging__LogLevel__Default='Trace' --rm -p 8085:80 -t --name proget \ 
    proget.inedo.com/productimages/inedo/proget:5.3.12

rhessinger

Hi @viceice,

Thanks for confirming that for me. I ran into a few issues on my test server with SQL 2014 and TLS1.2 support. You may want to make sure that TLS 1.2 is enabled on that VM. SQL Server 2014 and Windows Server 2012 R2 both had some unique issues with teh TLS 1.2 conversion (both needing updates to be able to enable them) . Although this did not cause an issue with hanging, it did cause my authentication to fail. You may want to check that.

Thanks,
Rich

viceice

Now moved to docker based sql server 2019 and it works. but now i get a new error in logs:

Product activation error: machine UID mismatch.
Expected: 5.3; Actual: G2fKz***redacted***tHtI=

rhessinger

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich