New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to start container on Linux 6.7 #868
Comments
I have the same issue. Found that it's the 6.7 kernel update. (#858 (comment)) Rolling back to 6.6.10 makes it work again. |
I experienced the same behavior today. First my existing container grew in size very quickly. I tried creating other containers but they all failed with the above message. It took me a while to figure out that downgrading my kernel fixes the issue, but downgrading to 6.6.11 did the trick. |
I can also confirm, I have the same behaviour. |
I downgraded my kernel and the container now functions. Is this limited to just this container or docker needing to update something to be compatible with the 6.7 kernel? |
I have same problem running container in Podman, but the Docker container is running without any problem. I simply pulled the image
Attached is a log file. |
Can confirm on Arch Linux, both the docker images for versions 2017, 2019 and 2022 and the AUR version give the same result.
After downgrading the kernel to version |
I can confirm this on Nobara 39 with 6.7.0 kernel. Exactly same issue for 2017, 2019, 2022 mssql. |
It seems like this was solved in the aur repo package |
For what it is worth: running Gentoo with custom 6.7.x kernel. $ docker run -it --rm -e ACCEPT_EULA=Y -e MSSQL_PID=Developer mcr.microsoft.com/mssql/server:2022-latest -- /bin/bash
sleep 1000 in another terminal, run ps fax|less
# find pid of bash which is parent of sleep
sudo strace -o mssql.strace -f -s1000 -p <bash-in-mssql-docker> return to the first terminal, $ grep -P '"/(proc|sys).*ENOENT' mssql.strace
9999 openat(AT_FDCWD, "/sys/fs/cgroup/memory/memory.limit_in_bytes", O_RDONLY) = -1 ENOENT (No such file or directory) |
I think the
|
The problem is still there with kernel 6.7.2 |
same problem on |
As a bad side effect the lsof process it spawns starts eating a core |
Hello, The issue has been identified and should be fixed in the next SQL Server 2022 CU, but we cannot commit to a specific CU release or timeline as sometimes plans can unexpectedly change. No further investigation or data points should be needed for this, but thank you all for reporting and for looking for potential causes. It is unrelated to cgroups, and at first glance it might be a kernel bug (but do not quote me on this) - it appears that as of 6.7, Knowing this, I cannot think of any workaround other than sticking to 6.6 in the meantime. |
Thank you very much for the patch. Are there plans to also backport it to 2019? |
Just wanted to write to say I am so glad you have all written on here, I didn't even think about the fact I just upgraded my arch system, I was about to start tearing things apart this has saved me a heck of a lot of time, whilst I am here to say thank you, I can also confirm this is still happening on Arch Linux on 6.7.4 |
Hi! We are running a msql based prosject on a mac and use the image |
Same issue with Fedora 39 on 6.7.2 and 6.7.3, but fine on 6.6.x and 6.5.x (in case anyone is searching for this issue and using Fedora). Looking forward to the CU @fbrosseau |
I think MSFT should strongly consider backporting this at least to SQL Server 2019 if not even 2017 as well. As people continue to upgrade their kernels this is going to be happening on an ever larger scale to existing SQL Server linux / container installations. |
Am I missing something? I do not see any updated Docker images for |
It should be included in the next CU, no date estimate
I've been keeping an eye on this page for a presumably CU12 to be released. |
In fedora I just followed these instructions using specifically this one command (as root, and make sure to have cd $(mktemp -d) && koji download-build --arch=x86_64 --arch=noarch kernel-6.6.14-200.fc39 && dnf upgrade * |
The image has been updated: It works for me again on Fedora 6.7.9-200.fc39.x86_64 |
Hello, Yes, sql22cu12 shipped today and it has the fix. The reason fixes are usually blurry on delivery dates and/or CU numbers is that schedules can shift (such as for making room for an urgent security fix, etc). SQL Server Linux follows the release cadence of SQL Server as a whole, and this schedule is usually quite rigid (minus security fixes). Sql19 should also be fixed for this in its next CU - their release schedules typically alternate one each month. However, sql17 will not be fixed, as sql17 is out of mainstream support and only receives security fixes. No bug fixes qualify for sql17. Customers who must remain on sql17 should keep kernel 6.6 or lower, although as usual we strongly recommend upgrading to a supported version of SQL Server for Linux, for many reasons including continued bugfixing. |
The merge is great news, was tracking that overnight. Any rough eta from merge to release available to pull down through the Bitwarden.sh? I gave it a shot about an hour ago and no luck yet |
Using Fedora 39, only tag 2022-CU12-ubuntu-22.04 works for me, not latest or 2022-latest. |
2022-latest works fine for me on Fedora 39 with kernel v 6.7.9-200.fc39.x86_64 |
I agree, I had to delete locally cached version :) |
Same here. Thanks a lot. |
2022-latest works perfectly on |
Not exactly related to the issue, but I upgrade to
The password specified in the
Has anyone had the same issue? |
Hi @sergiuser1 No, I don't have that error but I still using SA_PASSWORD, not MSSQL_SA_PASSWORD |
Turns out it was a race condition, and MSSQL was simply not completely up yet. I've added a healthcheck to it, and waiting for |
That's deprecated according to Microsoft: https://learn.microsoft.com/en-us/sql/linux/quickstart-install-connect-docker?view=sql-server-2017&tabs=cli&pivots=cs1-bash#run-the-container |
Is it possible to backport the 2022-latest fix but for azure-sql-edge v1? I'm using that version because I need arm64 support, which is currently deprecated in v2, and I can't use it anymore. |
an |
Yes. the fix included in 2022-CU12 Unfortunately, SQL Server 2019 havn't release a new cumulative-update with the fix. |
For me, I had to use MSSQL 2022 image instead 2019 and then everything worked (Of course previously, I got the last backup from the databases and restored it to the MSSQL 2022). |
Are there any plans for a SQL Server 2019 release? |
Looks like this has been fixed in Table here hasn't been updated here yet https://hub.docker.com/_/microsoft-mssql-server/ but checked the tag list and saw the new release (https://mcr.microsoft.com/v2/mssql/server/tags/list). All is working great now on macos, thank you! |
I can confirm that the latest version of |
Also confirming that 2019-latest resolved the issue under Linux 6.8.7, tested on Arch. |
Currently unable to start the container on Arch Linux as the host OS. The dump files for the failing sqlservr process don't really provide any insight as to why:
Docker-compose file:
Docker logs and data directory are set as UID:GID 10001:10001.
The text was updated successfully, but these errors were encountered: