Server won't run on Windows host, Linux container if using volumes

[rogerdawson]

We were trying to run the script below on a Windows host (Windows 10 Pro 1809+) configured for Linux docker containers as per these MS docs:

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=" -p 1433:1433 -v :/var/opt/mssql --name mssql -d mcr.microsoft.com/mssql/server:2017-latest

and the SQL server crashes on startup and the container stops running with a 'kernel bug error'. An image from 3+ weeks ago appears to be fine.

The container runs fine if I remove the host volume reference.

The container runs fine if running on a Linux host.

This problem occurs on multiple Windows PCs (4 different PC's).

It would appear 2017-CU14-ubuntu, 2017-latest, 2017 latest-ubuntu all have this problem (same image id's so expected), and we also tried 2019-CTP2.4 which has the same issue. An older image such as 2017-CU13 or earlier worked fine suggesting it's a problem with the latest releases.

Hi,

Could you share the docker version and file system information for analysis? Here is a similar thread. Docker mssql-server-linux crash when mounting a volume

[rogerdawson]

Hi,

we saw that thread and the one it refers to but they refer to messages about evaluation versions which we didn't see in our logs. They also seem to predate this problem, with it stretching back to 2017 and seemingly having no effective solution (people are getting it in January of this year though). As far as we can tell the issue we are seeing is only with the newest versions of the SQL server. Here is the other information you requested:

File System: NTFS, on 4 of the PC's. Have also tried mounting to a FAT formatted drive and this didn't work.

Docker Version: 18.09.2, Community edition

We don't believe this is a docker drive sharing issue, as the container does successfully write some of the files including the SQL error logs. We've also tried other containers that just write data to a file and they are fine. My PC was working fine but once I deleted the latest SQL image I had (most likely CU13), and got the very latest it stopped working, in an identical manner to the other 3 PC's we'd been trying to get working.

Thanks,

Roger

[tiptopdevelopment]

Any solutions? My mssql worked for like a month and then after restart it started giving me that error...

[jonny64bit]

Yeah i was getting the same problem. I had to go back to 2017-CU11-ubuntu to find a working verison.

[winterIslander]

2017-CU11-ubuntu did not work for me. @jonny64bit , could you share your docker command please?

[jonny64bit]

@winterIslander no problem.

docker network create netty docker run --name "SQL" --network="netty" -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=SqlServerSuperPassword2017" -p 1433:1433 -v C:/DockerData/SQL:/var/opt/mssql --restart=always -d mcr.microsoft.com/mssql/server:2017-CU11-ubuntu

[fourpastmidnight]

This is still happening as of SQL Server 2017 CU14 and 2019 CTP 2.5 using Docker Desktop and LCOW.

Docker Desktop: 2.0.4.0 (33772), Edge Engine: 19.03.0-beta3 Compose: 1.24.0 Windows 10 Enterprise 1809 (17763.475)

My organization does run Sophos Anti-Virus. I added dockerd.exe, com.docker.proxy.exe, Docker.Watchguard.exe, docker-compose.exe, and com.docker.service to A/V exclusions, as well as the D:\ContainerVolumes, C:\ProgramData\Docker and C:\ProgramData\DockerDeskotp folders since it was reported elsewhere that Symantec Endpoint Protection caused issues and Sophos has caused many issues for me with many things in the past as well. (I'm unable to turn off the A/V, nor uninstall it.)

I read in the very long issue #136 that CU11 and/or 12 worked (and possibly CU7, but I haven't tried that one yet), but alas, these versions didn't work either. I went backward from CU14 to CU9. Same error every time:

PS C:\src\git\MyApp> docker-compose up
Creating network "myapp_default" with the default driver
Creating myapp_db_1 ... done
Attaching to myapp_db_1
db_1  | This program has encountered a fatal error and cannot continue running at Sun May  5 04:55:08 2019
db_1  | The following diagnostic information is available:
db_1  |
db_1  |        Reason: 0x00000006
db_1  |        Status: 0x40000015
db_1  |       Message: Kernel bug check
db_1  |       Address: 0x6b844180
db_1  |    Parameters: 0x10861f680
db_1  |    Stacktrace: 000000006b92fc73 000000006b8441db 000000006b831422
db_1  |                000000006b83fe62 000000006b92e08a 000000006b92cb8d
db_1  |                000000006b96c0d2 000000006bcac000 000000006bc38000
db_1  |                000000006bc40000 0000000000000001
db_1  |       Process: 8 - sqlservr
db_1  |        Thread: 109 (application thread 0x4)
db_1  |   Instance Id: e3912638-f443-4bb1-93db-f3c6f0fce006
db_1  |      Crash Id: 825655cf-7d1a-4858-9c77-54fc9a9fbc9a
db_1  |   Build stamp: b2ce95e3a6684060d1d3bb1264841a1a8fc1d501ed6d1cfdb89cfcdde8048253
db_1  |  Distribution: Ubuntu 16.04.6 LTS
db_1  |    Processors: 2
db_1  |  Total Memory: 4107853824 bytes
db_1  |     Timestamp: Sun May  5 04:55:08 2019
db_1  |
db_1  | Ubuntu 16.04.6 LTS
db_1  | Capturing core dump and information to /var/opt/mssql/log...
db_1  | dmesg: read kernel buffer failed: Operation not permitted
db_1  | No journal files were found.
db_1  | No journal files were found.
db_1  | Attempting to capture a dump with paldumper
db_1  | Captured a dump with paldumper
db_1  | Core dump and information are being compressed in the background. When
db_1  | complete, they can be found in the following location:
db_1  |   /var/opt/mssql/log/core.sqlservr.05_05_2019_04_55_08.8.tbz2
myapp_db_1 exited with code 1

Here's the relevant portion of my compose file:

version: '3.7'

services:
  db:
    image: mcr.microsoft.com/mssql/server:2017-CU14-ubuntu
    ports:
      - "11433:1433"
    environment:
      ACCEPT_EULA: "Y"
      SA_PASSWORD: "p@55w0rd"
    volumes:
      - D:\ContainerVolumes\MyApp\MSSQL\SysDbs:/var/opt/mssql
      - D:\ContainerVolumes\MyApp\MSSQL\AppDbs:/var/opt/sqlserver
      #- myapp-sysdbs:/var/opt/mssql
      #- myapp-appdbs:/var/opt/sqlserver

    # I needed this because even though supposedly SQL Server 2017 is supposed to now support
    # VMs with only 2GB memory, I got an error saying I needed at least 2Gb memory.
    # This may have been a leftover since the Docker page for MSSql for Linux says the latest tag
    # is CU3 (and that's what I started with) even though it's not when you view _all_ tags (which
    # lead me to the CU14 image). 
    mem_limit: "4gb"
    healthcheck:
      test: [ "CMD", "sqlcmd", "-U", "sa", "-P", "p@55w0rd", "-Q", "select 1" ]
      interval: 1s
      retries: 20

# Tried this per another issue thread on GH
#volumes:
#  myapp-sysdbs:
#    external: true
#  myapp-appdbs:
#    external: true

I was able to successfully start the container by NOT using volume maps (either volumes or bind mounts). I was able to docker cp the files out of var/opt/mssql to my host bind mounts and then start the container using the bind mounts just fine. But alas, even this stopped working. I've looked at all log files I could find. After looking through the log files, it appears there's an issue with accessing the host filesystem (using either bind mounts or the external docker volumes), which is causing the above kernel bug check, specifically when SQL Server attempts to create the system databases.

For now, I'm going to have to resort to "rolling my own image" for Windows because a) these Linux images just don't work and b) you guys aren't keeping the Windows images updated. 😞 [That last statement, while technically, true, really means that I need to build my own image using the provided Dockerfile in this repository, as the Dockerfile (I believe) will result in an up-to-date image of SQL Server 2017 with all the CUs applied.]

[yang-zhang-syd]

I am having the same problem with mcr.microsoft.com/mssql/server:2017-latest which I cannot mount to local persistent volume. Switching to mcr.microsoft.com/mssql/server:2017-CU11-ubuntu works for me.

[Calvin-Yuhui-Liu]

Thanks @yang-zhang-syd ! Just confirmed the server:2017-latest doesn't, server:2017-CU11-ubuntu works.

[watfordgnf]

On Windows 10 1809, I can confirm that server:2017-latest, server:2017-CU14-ubuntu, server:2017-CU13-ubuntu, server:2017-CU12-unbuntu, server:2017-CU11-ubuntu all fail with the following (version numbers may differ):

PS C:\scratch\docker\compass> docker logs 7642a00dde90
This program has encountered a fatal error and cannot continue running at Mon Jul  1 14:12:46 2019
The following diagnostic information is available:

       Reason: 0x00000006
       Status: 0x40000015
      Message: Kernel bug check
      Address: 0x6b444180
   Parameters: 0x10861f680
   Stacktrace: 000000006b52fc73 000000006b4441db 000000006b431422
               000000006b43fe62 000000006b52e08a 000000006b52cb8d
               000000006b56c0d2 000000006b8ac000 000000006b838000
               000000006b840000 0000000000000001
      Process: 14 - sqlservr
       Thread: 25 (application thread 0x4)
  Instance Id: ec8d52df-1b70-4881-92d0-8a242c5fbe4b
     Crash Id: fd46606b-f34b-4501-858f-712c66824aa9
  Build stamp: b2ce95e3a6684060d1d3bb1264841a1a8fc1d501ed6d1cfdb89cfcdde8048253
 Distribution: Ubuntu 16.04.6 LTS
   Processors: 2
 Total Memory: 2061176832 bytes
    Timestamp: Mon Jul  1 14:12:46 2019

Ubuntu 16.04.6 LTS
Capturing core dump and information to /var/opt/mssql/log...
dmesg: read kernel buffer failed: Operation not permitted
No journal files were found.
No journal files were found.
Attempting to capture a dump with paldumper
WARNING: Capture attempt failure detected
Attempting to capture a filtered dump with paldumper
WARNING: Attempt to capture dump failed.  Reference /var/opt/mssql/log/core.sqlservr.14.temp/log/paldumper-debug.log for details
Attempting to capture a dump with gdb
Captured a dump with gdb
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.07_01_2019_14_12_46.14.tbz2

Launched with:

docker run -m 2GB -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=so-secret" -p 1401:1433 -v datavolume:/var/opt/mssql -d mcr.microsoft.com/mssql/server:2017-blah-blah

I'm still searching for something, anything, that works with SQL Server for Docker. (this is after going through a few versions of Docker for Windows itself to even run the container)

Same can be said for CU's 9 and 10, and 2019's CTP.

[apozgaj]

I am trying to run the same thing inside of the Kubernetes that comes with Docker for Windows and I'm getting the same error as mentioned above.

I was able to get the docker container run with the mounted volume (using docker comands) when I was targeting :2017-CU11-ubuntu tag but when I pushed the same thing into the k8s cluster, it crashed and the behavior was the same (immediatelly after couple of seconds the container would crash) and the error was the one mentioned above.

[sirio3mil]

Same for me, reported here

[tristanvandam]

Also getting the same issue. running the following compose:

db:
    image: mcr.microsoft.com/mssql/server:2017-latest-ubuntu
    container_name: localDb
    ports:  
      - "1433:1433"
    environment:
      SA_PASSWORD: "MySuperRandomStrong!Passw0rd!"
      ACCEPT_EULA: "Y"
    volumes:
      - C:\Docker\MountedVolumes\mySqlServerData:/var/opt/mssql

[rustedwizard]

Running into same issue. Here is my docker command: docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Michael@19891223" -p 1433:1433 -v C:/SQLServerData:/var/opt/mssql -d mcr.microsoft.com/mssql/server:2017-latest-ubuntu Here is the log message on console: PS C:\Users\RustedWizard> docker logs --details ac911a534bc4 This program has encountered a fatal error and cannot continue running at Sat Jul 27 07:37:27 2019 The following diagnostic information is available:

    Reason: 0x00000006
   Message: Kernel bug check
   Address: 0x6b647230
Parameters: 0x10861f670
Stack Trace:
            000000006b732f12
            000000006b64728b
            000000006b634126
            000000006b642cb2
            000000006b731240
            000000006b72fbc9
            000000006b7733f1
   Process: 7 - sqlservr
    Thread: 11 (application thread 0x4)

Instance Id: 562485c4-9f0c-427d-bb73-e04ca6dea42a Crash Id: c9ffb12b-6950-457c-bece-7daeb34d33a3 Build stamp: 6a405dcedd411942c879f001e943cd731ae3fa28b55f3d29fc3c2c88dcc1f7d5 Distribution: Ubuntu 16.04.6 LTS Processors: 8 Total Memory: 3413204992 bytes Timestamp: Sat Jul 27 07:37:27 2019

Ubuntu 16.04.6 LTS Capturing core dump and information to /var/opt/mssql/log... dmesg: read kernel buffer failed: Operation not permitted No journal files were found. No journal files were found. Attempting to capture a dump with paldumper WARNING: Capture attempt failure detected Attempting to capture a filtered dump with paldumper WARNING: Attempt to capture dump failed. Reference /var/opt/mssql/log/core.sqlservr.7.temp/log/paldumper-debug.log for details Attempting to capture a dump with gdb WARNING: Unable to capture crash dump with GDB. You may need to allow ptrace debugging, enable the CAP_SYS_PTRACE capability, or run as root.

[sirio3mil]

This is the workaround that works for me, I create a docker volume to persist data between containers and add a host folder to temp in order to share backups between container and host machine

mssql:
        image: reynier3mil/centos-mssql-full:latest
        container_name: mssql
        volumes:
            - mssql:/var/opt/mssql
            - ./data/mssql/backups:/tmp/backups
        ports:
            - 1433:1433
        networks:
            - api-network
        environment:
          - ACCEPT_EULA=Y
          - MSSQL_SA_PASSWORD=****************
          - MSSQL_PID=Developer
          - MSSQL_AGENT_ENABLED=true

Also SSMS is really slow finding local folders but using Azure Data Studio everything goes smoothly.

[MordantWastrel]

We have the same problem on Ubuntu 16.04 LTS where we use MSSQL 2019 in development. It worked fine under CTP3.1. Oddly enough, our windows machines worked fine when we updated to CTP 3..2, but our native ubuntu machine failed with a core dump and the demsg: operation not permitted error. We rolled back to CTP 3.1 and it works again.

We use a regular Docker volume (not bind mount) for data storage.

[MordantWastrel]

We have the same problem on Ubuntu 16.04 LTS where we use MSSQL 2019 in development. It worked fine under CTP3.1. Oddly enough, our windows machines worked fine when we updated to CTP 3..2, but our native ubuntu machine failed with a core dump and the demsg: operation not permitted error. We rolled back to CTP 3.1 and it works again.

We use a regular Docker volume (not bind mount) for data storage.

[MordantWastrel]

Started getting this today on Docker for Windows after an update. Tried deleting and re-creating the volume with no luck. Finally got it to work by adding some resource specifications and privileged: true to docker-compose.yml -- the privileged flag may not be necessary but haven't had a chance to play with it yet:

cpus: 1.0

mem_limit: 2g memswap_limit: 3g mem_reservation: 1024m privileged: true

[Zetanova]

The latest image had this problems some time ago so i switched back to CU12 But now i got this problem again.

I am using k8s with smb3 flexvolumes

The k8s cluster is used for developing and is running under hyper-v with dynamic memory k8s v1.15.0 CentOs 7 Linux 5.2.1-1.el7.elrepo.x86_64 (updated to 5.2.8-1.el7.elrepo.x86_64) Docker 18.9.7 (updated to docker://19.3.1)

What i tested without any success: updated cifs/samba-client to latest version updated the mount dialelct from SMB3.0 to SMB 3.1.1 downgraded dialect to SMB2.0 and SMB2.1 tested blank startup of CU7 to CU16 Build my own docker image with centos as base and "yum update -y"

The result with the latest updates and version is that the error "Directory not found" comes persistent on the mssql directory folder init, with CU12 it happend only sometimes on first db file usage, like tempdb

[vitalybibikov]

Starting from some version, it requires some changes in the volume's path to be done:

does not work: docker run -it --restart=always -p 1433:1433 --network=some-network --name mssql -v C:\docker-db:/var/opt/mssql/ mitpdocker.azurecr.io/mssql:v1.0.14

OK: docker run -it --restart=always -p 1433:1433 --network=some-network --name mssql -v C:\docker-db**data:/var/opt/mssql/data**/ mitpdocker.azurecr.io/mssql:v1.0.14

Though, docs update might be required

[Zetanova]

I tested it now again with a fresh deploy and mount only into /data and /log. It could init completely and i could create one database but after ~5min idle it crashed again as before

Reason: 0x00000001 Signal: SIGSEGV - Segmentation fault (11) Stack: IP Function

---

             0000563c5324ce6a std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
             0000563c5324c969 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
             0000563c53279796 malloc_usable_size+0x166d6
             0000563c531edde8 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
             00007fd29f03c390 __restore_rt+0x0
             00007fd29c3e6168 __nss_passwd_lookup+0x97c8
             0000563c531e7b58 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
             0000563c531e6e4f std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
    Process: 8 - sqlservr
     Thread: 23 (application thread 0x30)
Instance Id: 26031d73-2bbd-456e-a492-e3e943526eca
   Crash Id: b25e2c54-94b4-44b5-b2a1-17a4f8e185c4
Build stamp: fad5947c34c3f4acfa527fa10979e5c9b3c7dc2811fe1019283ffcb88e85c5c1

Distribution: Ubuntu 16.04.6 LTS Processors: 4 Total Memory: 11036069888 bytes Timestamp: Thu Sep 5 15:18:31 2019

[vitalybibikov]

Do you have any docker container logs?

Might it be just an expired evaluation period - from now on, you need to specify either your key/whatever or ENV MSSQL_PID=Developer that you are using the server as a developer.

[Zetanova]

Yes, i did and its a segfault Meaning that the c++ code wanted to access a memory address that it should not try too.

I think, the issue comes from some kind of kernel/base-image security fix. The mssql team is rebuilding old CU images when the base-image rebuilds because of some security fixes.

That could explain that old versions are failing now too CU13, CU14 worked for me on SMB for a while and now not anymore.

[nrmncr]

I have this issue. Windows 10 x64 Pro with all updates at current date, latest version of docker.

When running containter from 2017-latest image (command from docs tutorial), container stay running 5-10sec and than stops. docker logs:

This program has encountered a fatal error and cannot continue running at Wed Sep 11 11:33:24 2019
The following diagnostic information is available:

         Reason: 0x00000006
        Message: Kernel bug check
        Address: 0x6ae47d10
     Parameters: 0x10861f590
    Stack Trace:
                 000000006af345c6
                 000000006ae47d6b
                 000000006ae3451e
                 000000006ae43015
                 000000006ae431e6
                 000000006af32938
                 000000006af314ef
                 000000006af747c1
        Process: 7 - sqlservr
         Thread: 11 (application thread 0x4)
    Instance Id: 289cc91c-0f00-4972-b3c9-835633387d37
       Crash Id: 0b2a6810-d86d-4347-aef0-377538ceac5b
    Build stamp: fad5947c34c3f4acfa527fa10979e5c9b3c7dc2811fe1019283ffcb88e85c5c1
   Distribution: Ubuntu 16.04.6 LTS
     Processors: 2
   Total Memory: 2096140288 bytes
      Timestamp: Wed Sep 11 11:33:24 2019
     Last errno: 2
Last errno text: No such file or directory

Ubuntu 16.04.6 LTS
Capturing core dump and information to /var/opt/mssql/log...
dmesg: read kernel buffer failed: Operation not permitted
No journal files were found.
No journal files were found.
Wed Sep 11 11:33:25 UTC 2019 Capturing program information
Wed Sep 11 11:33:26 UTC 2019 Attempting to capture a dump with paldumper
Captured a dump with paldumper
Wed Sep 11 11:33:32 UTC 2019 Capturing program binaries
Wed Sep 11 11:33:33 UTC 2019 Compressing the dump files

When run container from image 2017-CU11-ubuntu, this works fine. When run from any image without using -v binding container works fine.

[riker09]

I can confirm that moving the data directory from /var/opt/mssql to /var/opt/mssql/data has solved the issue for me. Although, to be fair, I stopped the container, killed the volume and started everything up again.

[reubensultana]

Followed the above and defined the SQL Server directories to the ones on my host machine (Docker on Windows). The following steps & commands worked for me:

[string] $sqlRootFolder = "C:\DOCKER\MSSQL";
[string] $containerName = "sql01"

# create volume on host
if ((Test-Path "$sqlRootFolder\$containerName") -eq $false) {
    New-Item "$sqlRootFolder\$containerName" -ItemType Directory  | Out-Null;
}
New-Item "$sqlRootFolder\$containerName\DATA" -ItemType Directory -ErrorAction SilentlyContinue | Out-Null;
New-Item "$sqlRootFolder\$containerName\BACKUP" -ItemType Directory -ErrorAction SilentlyContinue | Out-Null;
New-Item "$sqlRootFolder\$containerName\LOG" -ItemType Directory -ErrorAction SilentlyContinue | Out-Null;

# Pull the SQL Server 2019 GA Linux container image from Microsoft Container Registry.
docker pull mcr.microsoft.com/mssql/server:2019-GA-ubuntu-16.04

# Create the SQL Server 2019 on Ubuntu Linux container
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=P@ssw0rd" -e "MSSQL_PID=Evaluation" -e "MSSQL_AGENT_ENABLED=true" -e "MSSQL_ENABLE_HADR=true" `
    -v "$($sqlRootFolder)\$($containerName)\data:/var/opt/mssql/data" `
    -v "$($sqlRootFolder)\$($containerName)\log:/var/opt/mssql/log" `
    -v "$($sqlRootFolder)\$($containerName)\backup:/var/opt/mssql/backup" `
    -p 1433:1433 `
    --name $containerName `
    -d mcr.microsoft.com/mssql/server:2019-GA-ubuntu-16.04

[paleocomburo]

I have the same issue and can confirm that the work-around above works. By explicitly adding directory mappings for the data, log and backup directories SQL Server does not crash for me.

[CraigHead]

I have the same issue and can confirm that the work-around above works. By explicitly adding directory mappings for the data, log and backup directories SQL Server does not crash for me.

I just mapped the data dir.

-v C:/Docker/Databases:/var/opt/mssql/data

[arthr]

I am having the same problem with mcr.microsoft.com/mssql/server:2017-latest which I cannot mount to local persistent volume. Switching to mcr.microsoft.com/mssql/server:2017-CU11-ubuntu works for me.

worked for me! thx!

[robbaman]

I'm getting this same issue. I'm on Windows 1903 and using Docker Desktop 2.1.0.5 (not the newer 2.2.0.0 since this gives me other issues), but when I run the following command to start 2017CU14:

docker run 
  -e "ACCEPT_EULA=Y" 
  -e "SA_PASSWORD=saSA123!" 
  --name sql 
  -p 11433:1433 
  -v C:\DockerData\SqlServer:/var/opt/mssql 
  -d 
  mcr.microsoft.com/mssql/server:2017-CU13-ubuntu

I get the following error:

This program has encountered a fatal error and cannot continue running at Wed Jan 22 10:27:49 2020
The following diagnostic information is available:

       Reason: 0x00000006
       Status: 0x40000015
      Message: Kernel bug check
      Address: 0x6b044180
   Parameters: 0x10861f680
   Stacktrace: 000000006b12fc73 000000006b0441db 000000006b031422
               000000006b03fe62 000000006b12e08a 000000006b12cb8d
               000000006b16c0d2 000000006b4ac000 000000006b438000
               000000006b440000 0000000000000001
      Process: 7 - sqlservr
       Thread: 11 (application thread 0x4)
  Instance Id: 4ca7a5f1-ea0b-4293-b1ee-b3e11c153a10
     Crash Id: e1c3e68e-f05c-421f-abeb-123856918f3f
  Build stamp: b2ce95e3a6684060d1d3bb1264841a1a8fc1d501ed6d1cfdb89cfcdde8048253
 Distribution: Ubuntu 16.04.6 LTS
   Processors: 2
 Total Memory: 2096140288 bytes
    Timestamp: Wed Jan 22 10:27:49 2020

Ubuntu 16.04.6 LTS
Capturing core dump and information to /var/opt/mssql/log...
dmesg: read kernel buffer failed: Operation not permitted
No journal files were found.
No journal files were found.
Attempting to capture a dump with paldumper
Captured a dump with paldumper

If I switch to using CU13-ubuntu or remove the -v volume binding to my local disk, the problem goes away.

[abaazzi]

Fixed this by using /var/opt/mssql/data as mount path instead of /var/opt/mssql/

https://forums.docker.com/t/sql-container-exits-immediatly-when-run-with-persistent-storage/61414/4

[croblesm]

mcr.microsoft.com/mssql/server

Not entirely sure if you already fixed your problem, but here you have a couple of examples on how to use volumes:

Using a known path from your host

docker run \
-e "ACCEPT_EULA=Y" -e "SA_PASSWORD=MyPassword" \
-p 1433:1433 \
-v D:/Data:/var/opt/mssql \
--name mssql \
-d mcr.microsoft.com/mssql/server:2017-latest

In this case, the volume will use a known path from the Docker host D:/Data

Using a default path with Docker volumes

docker run \
-e "ACCEPT_EULA=Y" -e "SA_PASSWORD=MyPassword" \
-p 1433:1433 \
-v vlm_MyData:/var/opt/mssql \
--name mssql \
-d mcr.microsoft.com/mssql/server:2017-latest

In this case, Docker will create a new volume called MyData. This volume will use the default path defined in Docker's setting to store all the container data.

You can also map the "Data" and "Log" default locations to volumes using the MSSQL_DATA_DIR and MSSQL_LOG_DIR environment variables.

[tracker1]

Could it be Antivirus on your host OS? Also, in my experience using volumes from Windows or MacOS hosts is significantly slower. As suggested above, usually create a volume container in docker if I need persistence and use a host volume mount only for a backup directory that isn't actively read/write like the data and log directories tend to be.

[SidShetye]

When can we expect a docker release with a fix for this? The workaround of mapping /var/opt/mssql sub-folders individually helps but not after wasting a lot of time and finally finding this thread. Others will be wasting their time over this too.

On a related note, are there any issues with only mapping/persisting the /var/opt/mssql/data folder while leaving the secrets, log and .system unmapped/in-container? Obviously not in production ... just in test environments.

[tutul2010]

Hi All, I ) tried to create an api on dotnetcore2.2 that was pulling data(DB table) from a Linux-DB containers by using 'mcr.microsoft.com/mssql/server:2017-CU11-ubuntu' or 'mcr.microsoft.com/mssql/server:2017-latest' images.

2 )Linux-containers are created but api container is failing to connect to sql-db container as below ERROR msg is coming "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: 35 - An internal exception was caught)". As i am using Dev environment (host) as win 10- Pro , Version 10.0.18362 -Build 18362 and docker-desktop,version:2.3.0.4(46911)-Engine:19.03.12 .

Any update on solutions or should we deploy 2 containers to azure app server for Linux or aci and test ?

Thanks

[martinandersen3d]

Solution:

Adding the user: root part works for me.

Running ubuntu on host.

This is my file:

docker-compose.yml

version: "3.7"
services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2019-latest
    container_name: sqlserver
    user: root   #####################   <<<<<<<<< IMPORTANT!!!!!  ############
    ports:
    #   host-port:container-port 
      - "1433:1433"
    environment:
      # SA_USERNAME: sa
      SA_PASSWORD: Dev1234!
      ACCEPT_EULA: Y
    volumes:
      - ./volumes/data2:/var/opt/mssql/data

I have been searhing for hours

[tonyctp]

Solution:

Adding the user: root part works for me.

Running ubuntu on host.

This is my file:

docker-compose.yml

version: "3.7"
services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2019-latest
    container_name: sqlserver
    user: root   #####################   <<<<<<<<< IMPORTANT!!!!!  ############
    ports:
    #   host-port:container-port 
      - "1433:1433"
    environment:
      # SA_USERNAME: sa
      SA_PASSWORD: Dev1234!
      ACCEPT_EULA: Y
    volumes:
      - ./volumes/data2:/var/opt/mssql/data

I have been searhing for hours

Yes, When i follow this step, i could start container the same with you, so it looks like is caused by MSSQL images' issues.... LOL...