Docker mssql-server-linux crash when mounting a volume #136
Comments
|
This looks a lot similar to another "Kernel bug check" in #99 |
|
The difference is he blames NFS, I use a local Windows drive. It looks like it's an issue introduced in RC1. I'm currently trying to run the same command (different local path of course) from my private notebook (openSUSE Tumbleweed and 17.04.0-ce) and it works fine. Will try it also with one of the CTPs. |
|
ctp2-1 is working fine. |
|
2 hours ago the new rc2 tag has been pushed. Same issue, though ... :( |
|
I am having the same issue (I think).
No issue when running without the volume. This is docker on windows. |
|
After getting the dump the container stops, so it is correct that it is gone. You can find the logs at your mounted volume (c:/data/mysql/data). |
|
Here is what's in my volume:
Not sure how to open these though. |
|
Here is a log from docker: compose file: |
|
You can only see the databases as you are only mounting the data volume instead of the whole mssql volume: /var/opt/mssql (not /var/opt/mssql/data). |
|
New compose file: Output from Here's a log from Looks like the same problem. Logs: |
|
In the meantime, this seems to work fine. So it appears that this is only a problem when mounting the volume from the host machine. |
|
And only on Docker for Windows 10. Works splendid on openSUSE as host system. |
|
I have the same problem and have reverted to tag ctp2-1, which is working fine. |
|
@benze: what host system are you running? Local mount or network share? |
|
I have this problem as well. It used to work fine like a week ago. Since then a new Docker version was released. I have no idea what version that was though. Currently on Docker for windows version 17.06.1-ce, build 874a737 I'd appreciate a fix or workaround as reverting to ctp2-1 (on which volumes currently do work) is not really a improvement for me. Recreating and seeding the databases is actually faster on rc2 than remounting on ctp2-1. |
|
@aerkefiende: I'm running in a Win 10 box, with local mount drives. Running Docker Engine 17.06.1-ce-win24 (13025). Using Docker for Linux Containers. |
|
Same problem encountered on Win10, Version 17.06.2-ce-win27 (13194), LinuxVM |
|
This is a known bug. It is fixed in the RTM/GA release which will be available soon. Alternatives for now: Use :ctp2-1 or email me for a special preview image. Please only email me if this is a significant problem for you and you can't use :ctp2-1 for some reason. It takes some effort on my side to be able to set you up to pull the special preview image from our private preview registry. Email address is twright @ microsoft Sorry for the inconvenience! |
|
now that |
|
Volume mappings are working again. I just tried both GA and latest and can confirm that the issue is fixed. |
|
I'm running into this problem now, after being forced to upgrade to 2017-GA since the CTP2 tags are no longer hosted on docker hub. Same error as sangohan posted a few hours ago. I found that if I explicitly mount a local directory into the /var/opt/mssql container location then the problem goes away. So it looks like I have a workaround. For those that might be wondering why I didn't already specify a mount point, it's because I use this container for automated testing so there was never a need to persist the test data once the container shutdown. Also, the problem did not occur locally on Docker for Mac. However it was consistently happening when running on a Local SSD-backed EC2 instance. |
|
@twright-msft: works like a charm for me! Now I only need the option to create a database at startup and I'm happy. |
|
@jertel's workaround seems to work. I am still testing it out on the EC2 agents i use. |
|
Closing the issue as noone complained so far :) |
|
I'm actually still using the ctp-2 container I have on my machine for the next couple of weeks; I can't afford the time right now to validate that the final version works properly. I'll post my findings as soon as I test it. Does the final release have the same 180 day eval license restrictions, or has that changed? |
|
The General Availability (GA) release is not timebombed. If you choose MSSQL_PID=Evaluation it will be limited to 180 days, but realistically I dont know why you would use that. If you want to just do demo, eval, testing, dev you can use MSSQL_PID=Developer (which is the default if you don't specify MSSQL_PID). |
|
I ran into exactly the same issue when updated to the latest release a few days ago. My container loses data during restarts. Is there any way to get the fixed image or some previous tag without this issue? |
|
Occurs on other mounts as already reported; Windows 10, v1709, 16299.309 |
|
Had the same problem as @staff0rd above using Solved it by deleting the images and re-installing it. Host OS type (Windows, Linux incl. which distro): Mac OS X |
|
A fix for the SQL startup issue on Docker for Windows when /var/opt/mssql is mounted is scheduled to be released in CU7. Specifically, this will fix the issue that shows the following in errorlog: 2018-01-10 19:40:40.17 spid6s Database 'master' running the upgrade step from version 862 to version 863. |
|
CU7 is the monthly cumulative update release that is scheduled to come out in the middle of next month (May). |
|
@anikammsft @twright-msft any issue or commit links to satisfy my curiosity? |
|
I just spent the better part of the day dealing with "Error: 17053/Operating system error 31" when trying to restore a backup on macOS High Sierra 10.13.4. I tried a bunch of solutions but in the end resizing my Docker image size from 16 GB to 32 GB fixed the issue. |
|
I have the same problem with CU11. Host OS: Ubuntu 18.04 with VirtualBox 5.2.18 When mounting a volume pointing to a VirtualBox Shared Folder that's hosted on the host machine, SQL Server crashes, even though it's able to create a number of files before doing so. Mounting volume pointing to a folder on the guest OS instead works, but is not a practical setup as I'd like to have minimal data on the container hosts. |
|
I have the same issue with CU12. If I mount a volume to CIFS or NFS then SQL crashes after a few minutes. Different error though: Host OS: ESXi 6.0U3 Like some of the other comments, it creates the directory structure just fine in the persistent storage and I can even use the SQL server (until it crashes). I've tried getting the image from Docker Hub and MCR but both have the same issue. If I remove the persistent volume, the server runs normally. |
|
I'm having the except same issue as @MagellanTX. SQL crashes when using a mounted volume (same error msg). SQL works fine when not used with the volume. Host OS: Win 10 |
|
I have the same issue. SQL crashes when using a mounted volume on host machine, but works fine when the volume is on the virtual machine. |
|
I have this problem too with mcr.microsoft.com/mssql/server:2017-latest and mcr.microsoft.com/mssql/server:2019-CTP3.1-ubuntu on Windows Server 2019 version 1809. I cannot mount a data volume using the -v flag. docker logs give me following error: (2017-CU11-ubuntu does not have this problem though) |
|
Same for me, but I can use mcr.microsoft.com/mssql/server:latest but none of 2019 images. Reported here |
|
Hello, problem solved by upgrading our linux kernel (we applied 5.2) |
|
Docker Toolbox on Win7 problem still occurs. My compose file:
|
|
Same issue here, running docker desktop 2.1.1.0 on Windows 10 1803 when using a volume I have the following log output: @M0nsieurChat - how did you update the kernel? |
|
Same issue here, running docker desktop 2.1.0.2 on macOS 10.14.6 when using a volume I have the following log output: Here my docker-compse file: |
|
|
I've got this issue using the following run command...
Host OS: Windows 10 (all up to date) Log in mounted folder shows: |
What if I want to fire multiple container for multiple ms sql server? Then this code does not seem to work. |
As stated in the above link:
This volumes work fine. |
|
@suseu does that really work for you? I tried mounting data, log, secrets and even data directory on its own instead of whole mssql directory on my Docker for Windows, but I am still getting error. Without volumes used, this works fine, but nothing is persisted of course. So that comment on MS site seems pretty misleading unless I am doing something wrong. I even use init container in my k8s deployment to set correct owner of the data directory ( |
|
To be fair, I just tried this using command: What does not work for me is running this in kubernetes cluster on the Docker Desktop for Windows. There I actually mount things like in template below, which I thought should work just like when I execute docker command: No matter if I use SQL server 2017 or 2019 image. I always get error as in previous post. Only when I remove volumes, then this works fine, but without persistency in place. In the cluster that is also hosted in the Hyper-V on windows server 2016 on multiple RedHat VMs, this template works fine as well as in Azure managed k8s cluster. So I wonder what might be the issue in my case with Docker Desktop for Windows. |
|
In case anyone will encounter the same issue as myself, here is solution that worked for me. I have noticed that Docker Desktop for Windows by default pushes all volumes into |
|
I'm encountering the same issue with the following setup: I'm running Xubuntu 20.04 as host (kernel 5.4.0-42-generic), Docker version 19.03.12, build 48a66213fe from the official repo. Regarding the double quotes on volume: it doesn't matter if I run the command with or without them. Funny thing is, when I run the same line on Windows, it works. However I don't know exactly what is the docker version over there, because I don't have access to the box at the moment. What I'm sure is that on Windows, I run Windows 10 2004 with Docker on WSL 2 (Ubuntu 20.04) |
|
Using docker-compose worked for me! version: '3' |
SOLUTION:Thanks @LeonardoHabitzreuter it works Adding the user: root part works for me. Running ubuntu on host. This is my file: docker-compose.yml Thanks, has been searhing for hours |
|
Don't run your containers as root. Running as root is not a fix, but a dirty hack you can hurt yourself on. Instead, create the required directories on the volume with proper permissions. I find that this pattern works nicely, though it does make some assumptions about the UID/GID within the container, which is a problem if they change. I've also added a silly healthcheck because I need the status for |
and others
Setup:
Host-OS: Windows 10
Docker: 17.06.0-ce
Command:
docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=strong1Pass!' -e 'MSSQL_PID=Developer' --cap-add SYS_PTRACE -p 1433:1433 -v c:/users/pfliegel.sebastian/docker_vol/mssql:/var/opt/mssql -d --name mssql microsoft/mssql-server-linux:latestError:
When I try to run the container without attaching volumes it works just fine.
Dumplog is attached: log.zip
The text was updated successfully, but these errors were encountered: