Running MSSQL-Server Container with VIC
Article ID: 327269
Updated On:
Products
VMware vSphere ESXi
Issue/Introduction
Symptoms:
When performing a "docker -H VCH_IP:2376 --tls run -d --name MSSQL -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=L0ngP@ssw0rd!" -p 5533:1433 -d microsoft/mssql-server-linux:latest", it fails running after initialization with the following backtrace:
When performing a "docker -H VCH_IP:2376 --tls run -d --name MSSQL -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=L0ngP@ssw0rd!" -p 5533:1433 -d microsoft/mssql-server-linux:latest", it fails running after initialization with the following backtrace:
This program has encountered a fatal error and cannot continue running.
The following diagnostic information is available:
Reason: 0x00000003
Message: result
Stacktrace: 0000558a8289b692 0000558a82839817
Process: 274 - sqlservr
Thread: 278 (application thread 0x1000)
Instance Id: 1fff184b-9ed0-4ec3-b50a-e49be4d671d8
Crash Id: f1f44256-6586-45ad-983a-33ff3372dea9
Build stamp: 9e00c100bdacab600fdf5caa08122c645b8ce5d58b5c75bfe6ea02e1a1c9cc13
Capturing core dump and information...
No journal files were found.
No journal files were found.
Attempting to capture a dump with paldumper
/opt/mssql/bin/crash-support-functions.sh: line 185: 420 Aborted
$program_dir/paldumper $dokill -p $pid -d $paldumper_dump_type_str -o $dump_filename.gdmp > $paldumper_debuglog_filename 2>&1
WARNING: Capture attempt failure detected
Attempting to capture a filtered dump with paldumper
Core dump and information are being compressed in the background. When complete, they can be found in the following location:
/var/opt/mssql/log/core.sqlservr.05_16_2018_12_41_08.274.tbz2
The following diagnostic information is available:
Reason: 0x00000003
Message: result
Stacktrace: 0000558a8289b692 0000558a82839817
Process: 274 - sqlservr
Thread: 278 (application thread 0x1000)
Instance Id: 1fff184b-9ed0-4ec3-b50a-e49be4d671d8
Crash Id: f1f44256-6586-45ad-983a-33ff3372dea9
Build stamp: 9e00c100bdacab600fdf5caa08122c645b8ce5d58b5c75bfe6ea02e1a1c9cc13
Capturing core dump and information...
No journal files were found.
No journal files were found.
Attempting to capture a dump with paldumper
/opt/mssql/bin/crash-support-functions.sh: line 185: 420 Aborted
$program_dir/paldumper $dokill -p $pid -d $paldumper_dump_type_str -o $dump_filename.gdmp > $paldumper_debuglog_filename 2>&1
WARNING: Capture attempt failure detected
Attempting to capture a filtered dump with paldumper
Core dump and information are being compressed in the background. When complete, they can be found in the following location:
/var/opt/mssql/log/core.sqlservr.05_16_2018_12_41_08.274.tbz2
Environment
VMware vSphere Integrated Containers 1.0.x
VMware vSphere Integrated Containers 1.4.x
VMware vSphere Integrated Containers 1.x
VMware vSphere Integrated Containers 1.4.x
VMware vSphere Integrated Containers 1.x
Cause
This problem occurs because SQL Server 2017 on Linux is incompatible with legacy VA layouts. Because of settings that are enabled on the OS Kernel, all processes start by using legacy_va_layout.
During startup, SQL Server on Linux verifies the address ranges. When it finds an incompatibility because of a legacy VA layout, it raises an assert, terminates the program, and generates a core dump.
The OS Kernel might switch to using a legacy VA layout for either of the following reasons:
Source : https://support.microsoft.com/en-us/help/4134638/sql-server-2017-terminates-and-generates-a-core-dump-on-rhel-7-4-whenDuring startup, SQL Server on Linux verifies the address ranges. When it finds an incompatibility because of a legacy VA layout, it raises an assert, terminates the program, and generates a core dump.
The OS Kernel might switch to using a legacy VA layout for either of the following reasons:
- The soft stack limit value is set to Unlimited (for example, a modified limits.conf script or an ulimit -s setting).
- A global legacy VA layout is enabled (for example, sysctl vm.legacy_va_layout or modify /etc/sysctl.conf).
According to the Microsoft issue listed above, having the soft stack size limit set to Unlimited causes the Linux kernel to start a new process with a "legacy" address space layout. The Microsoft SQL Server crashes when that layout is chosen. The system variable "vm.legacy_va_layout" can also be used to force the "legacy" address space layout on all processes (not only on the ones with Unlimited stack size). However, Photon-OS (used by VIC) has that variable set to 0, by default. The real cause of the problem is the fact that the first VIC process, running in the container VM, sets the soft stack size limit to Unlimited and this setting in inherited by all the children processes including SQL Server. Since SQL Server is started with Unlimited, Photon OS chooses the legacy address space layout, causing the crash.
Resolution
No resolution at the time of writing.
We are still working on implementing a fix.
Workaround:
The current workaround is to create an updated image based on the mssql-server-linux provided by Microsoft, by adding a small script as entrypoint, which will set the correct value for the soft stack size, before launching the SQL Server service.
Using a machine with the Docker Engine installed :
2 - Create a bash script named start.sh
We are still working on implementing a fix.
Workaround:
The current workaround is to create an updated image based on the mssql-server-linux provided by Microsoft, by adding a small script as entrypoint, which will set the correct value for the soft stack size, before launching the SQL Server service.
Using a machine with the Docker Engine installed :
1 - Create a "MSSQL" folder, and Change Directory into it :
root@PhotonJumpBox [ ~/ ]# mkdir MSSQL
root@PhotonJumpBox [ ~/ ]# cd MSSQL
root@PhotonJumpBox [ ~/ ]# cd MSSQL
2 - Create a bash script named start.sh
Additional Information
The dch-photon container that comes standard in the VIC Appliance registry can be use in place of the docker engine if preferred. See more details about using the dch-photon container at the documentation section Building and Pushing Images with the dch-photon Docker Engine
Feedback
Yes
No
Powered by
3 - Copy the following content into the start.sh script :
# Leave the Container enough time to initialize
sleep 3
# Set the Soft Stack value
ulimit -S -s 8192
# Start MSSQL
/opt/mssql/bin/sqlservr
5 - Copy the following content into the Dockerfile file :
COPY start.sh /root/start.sh
CMD ["/root/start.sh"]
6 - Build new image
Sending build context to Docker daemon 8.192kB
Step 1/3 : FROM microsoft/mssql-server-linux
---> 306ce7d34f9b
Step 2/3 : COPY start.sh /root/start.sh
---> 8e3a5e9d952d
Removing intermediate container 0149f82dffb0
Step 3/3 : CMD /root/start.sh
---> Running in 8364e30c028b
---> 65d343071f54
Removing intermediate container 8364e30c028b
Successfully built 65d343071f54
Successfully tagged VIC_APPLIANCE_FQDN/default-project/mssql-server-linux:VIC
==> Replace VIC_APPLIANCE_FQDN with your own. You can as well change the Project Folder to your need.
The push refers to a repository [VIC_APPLIANCE_FQDN/default-project/mssql-server-linux]
e054723b734d: Pushed
9302eae228b7: Layer already exists
8a870f6cbd26: Layer already exists
45feb6b3c7be: Layer already exists
912a24c355e6: Layer already exists
bb83128af95f: Layer already exists
49907af65b0a: Layer already exists
4589f96366e6: Layer already exists
b97229212d30: Layer already exists
cd181336f142: Layer already exists
0f5ff0cf6a1c: Layer already exists
VIC: digest: sha256:fa125d4955e3c0b3fc07fb2a1c9ffe095e4d2904f5fd5ed6c89313b051a51eb1 size: 2620
8 - Execute Container
Unable to find image 'VIC_APPLIANCE_FQDN/default-project/mssql-server-linux:VIC' locally
VIC: Pulling from default-project/mssql-server-linux
ae79f2514705: Pull complete
5ad56d5fc149: Pull complete
170e558760e8: Pull complete
395460e233f5: Pull complete
6f01dc62e444: Pull complete
a3ed95caeb02: Pull complete
c28add6d31d0: Pull complete
f379b920b5be: Pull complete
876584dea625: Pull complete
0968afc1cd07: Pull complete
ab7526c4468e: Pull complete
062945c9e377: Pull complete
Digest: sha256:fa125d4955e3c0b3fc07fb2a1c9ffe095e4d2904f5fd5ed6c89313b051a51eb1
Status: Downloaded newer image for default-project/mssql-server-linux:VIC
40cce5cac6ac6527fb1bbfe49773296017f951ffb3df6871f0cfc2e277714c6c
CONTAINER ID IMAGE COMMAND CREATED > STATUS PORTS NAMES
40cce5cac6ac VIC_APPLIANCE_FQDN/default-project/mssql-server-linux:VIC "/root/start.sh" 6 minutes ago Up 4 minutes VCH_IP:5533->1433/tcp MSSQL
10 - Check that SQL Server is running
root@40cce5cac6ac:/# cd /opt/mssql-tools/bin/
root@40cce5cac6ac:/opt/mssql-tools/bin# ./sqlcmd -S localhost -U SA -P 'VMware123!'
1> CREATE DATABASE TestDB
2> SELECT Name from sys.Databases
3> GO
Name
--------------------------------------------------------------------------------------------------------------------------------
master
tempdb
model
msdb
TestDB
(5 rows affected)
1> QUIT
root@PhotonJumpBox [ ~/MSSQL ]#