How to enable remote debugging of Stored Procs with Linux container?

[benze]

I'm trying to use the Remote Debugger from within SSMS to debug a stored proc. However, I cannot connect to port 135 of the SQL container I spun up. I am launching my container in Linux with the following command:

 docker create --name mssql2 -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=P@$$12345'  -e -p 135:135  -p 1433:1433  -v /home/eric/docker/mssql:/var/opt/mssql -v /usr/share/zoneinfo:/usr/share/zoneinfo:ro -e TZ=America/Toronto microsoft\
/mssql-server-linux

docker start mssql2

When I try to telnet to port 135, however, the connection is immediately closed:

eric@localhost ~/docker $ telnet localhost 135
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

Logging into the mssql2 container and running netstat (after installing the net-tools package) I see:

root@2a378b0479d9:/etc# netstat -ano
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Timer
tcp        0      0 0.0.0.0:1433            0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:1434          0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 172.17.0.3:57064        91.189.88.162:80        TIME_WAIT   timewait (7.52/0/0)
tcp        0      0 172.17.0.3:36154        91.189.88.149:80        TIME_WAIT   timewait (54.62/0/0)
tcp        0      0 127.0.0.1:37135         127.0.0.1:1433          ESTABLISHED off (0.00/0/0)
tcp        0      0 127.0.0.1:40978         127.0.0.1:1433          TIME_WAIT   timewait (18.04/0/0)
tcp        0      0 127.0.0.1:1433          127.0.0.1:45665         ESTABLISHED keepalive (7051.49/0/0)
tcp        0      0 127.0.0.1:1433          127.0.0.1:37135         ESTABLISHED keepalive (7051.46/0/0)
tcp        0      0 127.0.0.1:45665         127.0.0.1:1433          ESTABLISHED off (0.00/0/0)
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   Path

So clearly MSSQL isn't even listening on port 135 within the container. What do I need to do to enable the remote debug port on the docker container? I do not even see any reference to port 135 in the logfile either.

Thanks,

Eric

[forkazmoden]

Hi benze,

In you command, the –p 135:135 means that you bind port 135 of the container to port 135 on 127.0.0.1 of the host machine. It doesn’t mean that you change the TCP port where SQL Server listens for connections to port 135. By default, SQL Server is listening on port 1433. You can see that port 1433 is being listened in the result of netstat. Please refer to Configure SQL Server container images on Docker.

[benze]

@forkazmoden I understand that SQL is listening on 1433; that is expected. I am looking to configure remote debugging for MSSQL. From what I read in the docs, the Transact-SQL debugger uses port 135 to communicate with the server. However, in this docker instance, the MSSQL server isn't even listening to port 135 within the container itself.

[forkazmoden]

@benze I tried it many ways. All failed. I got following error message in Visual Studio.

Unable to start program
‘MSSQL:://IP Address/?/sys/=0’
Operation not supported. Unknown error: 0x80004005.

I think it is not supported to use the Transact-SQL debugger for Linux containers by now.

[vin-yu]

@benze, the SQL Server container is not built with port 135 exposed. Can you try build your docker image from the SQL Server image and add a EXPOSE 135 to it?

[benze]

@vin-yu I'm not sure I understand what EXPOSE 135 will add to the container. Specifying -p 135:135 will expose the port explicitly, and as I mentioned, MSSQL itself isn't even listening to port 135 within the container itself. So I don't see how adding the EXPOSE instruction can make any difference.

At this point, my question is how to turn on the debug port of the MSSQL server itself; is it a configuration option in the server? Is it something the server executables need to be built with?

[vin-yu]

@benze, I followed up with the engineering team on this feature an hour ago. This is actually not enabled on Linux yet. We'll have to do some work on our side to enable this on the SQL Server side.

[ADustyOldMuffin]

Is there any progress on this feature?

[seanzamora]

@vin-yu Any updates on remote debugging support on Linux based containers?

[PIC16f841]

Any progress on this issue?

[ajsomeren]

My question is also: Any progress?? I need this

[turagittech]

Long overdue, do we have a rough timeline, is it on the roadmap? This really limits the use of Docker MSSQL for development of stored procedures.
Back to Print I guess

[srujalsk]

Hi Team,

Any update on this issue or timeline to fix this issue it is really frustrating to debug using PRINT statement

[tcartwright]

Just chiming in to see if / how this was fixed? We are wanting to debug stored procedures as well.

[JMC-PK]

Hey, almost 3 years later, id like to be able to debug ssms stored proceures with a docker container also.

[srujalsk]

I too wish, if we can get this feature enabled.

…

On Mon, 1 Nov, 2021, 9:39 pm JMC-PK, ***@***.***> wrote: Hey, almost 3 years later, id like to be able to debug ssms stored proceures with a docker container also. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#410 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOB7KKLO4UJKICMCX5WXSLUJ23S3ANCNFSM4GO7LFPA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[iamruss]

I vote for this feature!

[daniherculano84]

Another vote for this feature

[valamelkor]

We need this

[ajsomeren]

Please??

[bobinush]

3,5 years later.. any update?

[silverl]

An unstated detail in the original question is that the poster is running Windows as their host. I believe this because they mention using SQL Server Management Studio (SSMS), which is Windows-only.

Here's a related issue my team opened a while back: https://github.com/MicrosoftDocs/sql-docs/issues/5690

My theory is that what you ask for is not possible because the Windows host has already bound all available interfaces to port 135. Port 135 is the Windows RPC discovery service. You cannot get a container engine to listen on that port. Windows requires that it owns 135 for many, many different functions.

Have a look at this page Service overview and network port requirements for Windows. You can see how many services in Windows rely on port 135.

I would very much like to be proven wrong here.

[bobinush]

@silverl I guess that's the next issue.

@forkazmoden From what I read in the docs, the Transact-SQL debugger uses port 135 to communicate with the server. However, in this docker instance, the MSSQL server isn't even listening to port 135 within the container itself.

I read that as that the debugger already works on 135 but the key issue is mentioned in the second sentence.

[RiverHeart]

Would be nice to be able to debug these containers. A solid "we'd love to add this feature but are prioritizing other projects/issues/features at the moment and don't have an ETA on when resources would be available for this" would be better than radio silence.