Sql-Agent not starting on an Ubuntu SQL Server docker container in an azure container

Question

I am using docker to deploy an linux sql-server to azure.

And I cannot get the Sql-Server agent to run on a container instance on Ubuntu in azure. The Sql-Server starts fine but not the Sql-Agent. I have tried with different versions of SQL-Server.

Locally it works fine with this example:

docker run -d -p 15789:1433 `
--env ACCEPT_EULA=Y `
--env SA_PASSWORD=Testing1122 `
--env MSSQL_AGENT_ENABLED=True `
--name testcontainer `
mcr.microsoft.com/mssql/server:2019-GDR1-ubuntu-16.04

But when adding the same image to azure container registry and then to an container instance it is not working:

In the log for the container I can see the following error which I am not sure if it is correlated to that the agent is not starting:

2020-10-20 14:36:24.91 spid35s     Error: 39002, Severity: 16, State: 1.
2020-10-20 14:36:24.91 spid35s     SQL failed to boot extensibility for error code 0x80070005.
2020-10-20 14:36:24.91 spid35s     InitializeXdbPkgLauncher failed. ErrorCode: 0x80004005.

Someone that knows why this isnt working or how it can be fixed to be able to run it in an azure container instance?

Poverty

The plan was to use the agent to do scheduled backups, but for now (and maybe also later) I will use this service for scheduled backups: sqlbackupandftp.com which seems nice to have the backups in dropbox for example. – Poverty

Answer 1

We had a similar issue and we found out that this is due to a limitation that exists in azure container instances: sql agent can't be enabled (looks enabled but in reality it isn't) when the instance name is greater than 15 characters long. Unfortunately, instance names are auto-assigned by the Kubernetes cluster at container creation time and you have no control over that. Vote for this idea if you would like the issue to be addressed (https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/42509800-support-setting-of-hostname).

Orlov

as absurd as this is, it worked on first try. I'd upvote 10 times if I could. – Acrolein

(in my case I was able to assign a shorter hostname, that's what I mean with "it worked on first try". upvoted on the azure feedback anyways) – Acrolein

anyone hitting that as well, use a statefulset, this can have a name that is short enough – Archiphoneme

Answer 2

According to my test, the image mcr.microsoft.com/mssql/server:2019-GDR1-ubuntu-16.04 has the same error both in local and the Azure Container Instance. The issue shows here that it's a bug in SQL Server 2019. And I try to use the image mcr.microsoft.com/mssql/server:2017-CU21-ubuntu-16.04 and there is no problem. If you do not mind, try it.

Slipknot

Thanks for your suggestion. I tried to use the 2017 but unfortunately with the same results for my azure container instance. I dont understand why it works when i run it locally though. Not sure if it can have something to do with the issue described here: github.com/microsoft/mssql-docker/issues/503 – Poverty

@Poverty How do you test it the things go well? – Slipknot

I was running the docker container locally as command above on windows, that worked fine for me even with 2019. What about you? @Charles Xu – Poverty

@Poverty The image 2019 also does not work well in my local windows. It gives the same error. I guess there is something missed in my windows. – Slipknot

Thats weird, I will try on a different machine and let you know the results. – Poverty