The only known way to debug a Linux Azure web app is to create a TCP tunnel between your machine and Azure which is explained here.
I am able to create the tunnel, SSH and SFTP into the web app using the credentials given from Azure(127.0.0.1 and port) via terminal but having problems with adding the connection to Debug -> Attach to Process in Visual Studio 2022. The response is 'Could not connect to the remote system, connection timed out' and the stack is:
11:24:25.4599569 [Info, Thread 1] liblinux.RemoteSystemBase: Connecting over SSH to 127.0.0.1:63718
11:24:26.0743705 [Info, Thread 1] liblinux.IO.RemoteFileSystemImpl: Connecting over SFTP to 127.0.0.1:63718
11:24:56.0883458 [Info, Thread 1] liblinux.HostKeyVerifier: Connection failed.
11:24:56.0883458 [Info, Thread 1] liblinux.HostKeyVerifier: Renci.SshNet.Common.SshOperationTimeoutException: Socket read operation has timed out after 30000 milliseconds.
at Renci.SshNet.Abstractions.SocketAbstraction.Read(Socket socket, Byte[] buffer, Int32 offset, Int32 size, TimeSpan readTimeout)
at Renci.SshNet.Connection.ProtocolVersionExchange.SocketReadLine(Socket socket, TimeSpan timeout, List`1 buffer)
at Renci.SshNet.Connection.ProtocolVersionExchange.Start(String clientVersion, Socket socket, TimeSpan timeout)
at Renci.SshNet.Session.Connect()
at Renci.SshNet.BaseClient.CreateAndConnectSession()
at Renci.SshNet.BaseClient.Connect()
at liblinux.HostKeyVerifier.Connect(BaseClient client)
11:24:56.0883458 [Error, Thread 1] liblinux.IO.RemoteFileSystemImpl: Connection failure over SFTP to 127.0.0.1:63718
11:24:56.1130928 [Error, Thread 1] liblinux.IO.RemoteFileSystemImpl: Renci.SshNet.Common.SshOperationTimeoutException: Socket read operation has timed out after 30000 milliseconds.
at Renci.SshNet.Abstractions.SocketAbstraction.Read(Socket socket, Byte[] buffer, Int32 offset, Int32 size, TimeSpan readTimeout)
at Renci.SshNet.Connection.ProtocolVersionExchange.SocketReadLine(Socket socket, TimeSpan timeout, List`1 buffer)
at Renci.SshNet.Connection.ProtocolVersionExchange.Start(String clientVersion, Socket socket, TimeSpan timeout)
at Renci.SshNet.Session.Connect()
at Renci.SshNet.BaseClient.CreateAndConnectSession()
at Renci.SshNet.BaseClient.Connect()
at liblinux.HostKeyVerifier.Connect(BaseClient client)
at liblinux.IO.RemoteFileSystemImpl.ConnectCore()
11:24:56.1130928 [Info, Thread 1] liblinux.RemoteSystemBase: Disconnecting over SSH from "127.0.0.1:63718"
The SSH connection is working fine because on connect I have to accept the connection fingerprint so the problem is with the SFPT connection happening right after that.
Visual Studio 2022 17.1.6, latest
Any good ideas?
There are two correlated, but rather separate features at play 1) SSH, and 2) Remote Debugging
SSH
As of right now, to my knowledge, SSH into blessed containers-- code publish-- and custom containers-- Docker publish-- is still in "Preview" which means not feature complete, not recommended for production. Please see here (Open SSH from remote shell). Notably, that doc links here (Remote Debugging of Node.js Apps), which suggests Remote Debugging has been enabled for Node.js. However, this blog post is now four years old. Things have probably changed since. So, let's look at the remote debugging feature.
Remote Debugging
To tell if Remote Debugging is available for your current runtime and platform, open Azure portal and navigate to the site in question. Under settings Configuration, look for "Debugging" in the General settings tab. You will either be able to enable Remote Debugging (for instance, for Node.js publish, App Service Windows):
or you will see "Your selected runtime stack does not currently support remote debugging." (for instance, Node.js publish, App Service Linux, .NET 6 publish on App Service Windows):
UPDATE:
Regarding Visual Studio, VS2022 appears to use PORT 4026 as the default port; however, the port for Azure App Service is still 4024. Recent versions of VS appear to have reverted (17.2.0 and later). For versions prior to VS2022 17.2.0, using Debug\Attach, append port 4024 to the connection URL.
Related
All,
I am using SignalR (.net 6) and have couple of questions about SignalR Connections (specifically SignalR connections that use web sockets):
Q #1)
If the SignalR client crashes, will SignalR server dispose the underlying connection automatically for me (and the OnDisconnectedAsync() event will be fired)?
The idea is to dispose client resources (on the server, resource ex: NHibernate session) that are tied to each connection.
My Tests Indicate (on local machine, both server and client):
I tried to simulate this scenario where I had a running client which then I shut down with Task manager and the minute Windows released resources for the process, the SignalR server somehow detected that connection was lost and released the connection and OnDisconnectedAsync() was called. I am not sure if my test was sufficient for this use case (client crash). I am curious of how did the server know, was it the fact the maybe the finalizer for client connection ran?
Q #2) If the current connection between client and server is broken or interrupted and SignalR needs to reconnect, and it successfully reconnects, does it use the same connection (with the same connection ID/same web socket) or does it attempt create new connection (tied to a new web socket)?
https://learn.microsoft.com/en-us/aspnet/core/signalr/configuration?view=aspnetcore-6.0&tabs=dotnet
The server considers the client disconnected if it hasn't received a message (including keep-alive) in this interval. It could take longer than this timeout interval for the client to be marked disconnected due to how this is implemented. The recommended value is double the KeepAliveInterval value.
It assigns a new connection id. Consider using other data to track which user is it, eg. Checking in the on connect and on disconnect methods.
https://learn.microsoft.com/en-us/aspnet/core/signalr/groups?view=aspnetcore-6.0
While stress testing our application server we have got the following exception from Redis:
ServiceStack.Redis.RedisException: could not connect to redis Instance at redis-host:6379 ---> System.Net.Sockets.SocketException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full redis-host:6379
at System.Net.Sockets.Socket.Connect(IPAddress[] addresses, Int32 port)
at System.Net.Sockets.Socket.Connect(String host, Int32 port)
at ServiceStack.Redis.RedisNativeClient.Connect()
--- End of inner exception stack trace ---
at ServiceStack.Redis.RedisNativeClient.Connect()
at ServiceStack.Redis.RedisNativeClient.AssertConnectedSocket()
at ServiceStack.Redis.RedisNativeClient.SendCommand(Byte[][] cmdWithBinaryArgs)
at ServiceStack.Redis.RedisNativeClient.SendExpectData(Byte[][] cmdWithBinaryArgs)
at ServiceStack.Redis.RedisClient.GetValueFromHash(String hashId, String key)
at ServiceStack.Redis.Generic.RedisTypedClient1.GetValueFromHash[TKey](IRedisHash2 hash, TKey key)
It seems that there are connection limit exceeds on redis host port. Any idea how to increase this threshold through Redis.conf OR server configuration? We have hosted the Redis instance over Ubuntu server.
I was able to duplicate the same issue of buffer size limit exceeded using ServiceStack. The code to do the stress testing is here - run 20 instances of the application for at least 20 minutes. https://github.com/ServiceStack/ServiceStack.Redis/commit/b01582f9c873f375794c04d46aad400590ca5bf3
The first error you may see is "Could not connect to redis instance" as described by
Redis unable to connect in busy load, but if you expand the inner exception you see "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"
My problem occured on Window7, but not Window Server 2008 rc. So I begin to look at if it was an OS problem. After emailing Demis at ServiceStack, it was concluded that ServiceStack was closing the sockets correctly. Looking at the OS, the problem was fixed with setting TcpTimeWaitDelay and MaxUserPort.
More references. TcpTimeWaitDelay to 45 seconds
and MaxUserPort
http://mashijie.blogspot.com/2009/05/change-default-setting-of-tcp-ports.html
I adjusted the port range to 1025-64511
We have a WCF service hosted as a windows service with tcp bindings on our application server. We have a ASP.NET web application hosted on a separate web server that is attempting to connect to it. Both servers are Windows 2008 R2 machines.
The ASP.NET web application's application pool is set to use the ApplicationPoolIdentity as it's user. When we attempt to connect to the WCF service from the windows machine the following error occurs:
Source Exception: System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:09.9980000'. ---> System.IO.IOException: The read operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:09.9980000'. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, Boolean closing)
However, when we change the Application Pool's user over to Network Service it connects without error.
My question is two fold. Does anyone know why using the ApplicationPoolIdentity does not work, is it some sort of configuration issue? And, what would be downside of running the application pool under the network service account? I know the ApplicationPoolIdentity has less rights, making more secure, and is considered best practice.
The answer to this depends on the different configurations you have in your network, your servers and your service.
I've run into similar situations in the past where the ApplicationPoolIdentity doesn't have rights to 'talk' with resources outside of the machine.
Another issue could be around how do you handle the connections between your web application and the server. Are you reusing the same connection every time, or are you closing / reopening your channels? This msdn thread has some information on this.
I have a WCF service run on Windows Server 2008 RC2 IIS 7 with no firewall. When I trying to call it with netTcpBinding binding, I get this exception:
System.TimeoutException: The open
operation did not complete within the
allotted timeout of 00:00:30. The time
allotted to this operation may have
been a portion of a longer timeout.
---> System.TimeoutException: The socket transfer timed out after
00:00:30. You have exceeded the
timeout set on your binding. The time
allotted to this operation may have
been a portion of a longer timeout.
---> System.Net.Sockets.SocketException: A
connection attempt failed because the
connected party did not properly
respond after a period of time, or
established connection failed because
connected host has failed to respond
at
System.Net.Sockets.Socket.Receive(Byte[]
buffer, Int32 offset, Int32 size,
SocketFlags socketFlags) at
System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[]
buffer, Int32 offset, Int32 size,
TimeSpan timeout, Boolean closing)...
The method I call just returns a numeric value, nothing else, so the problem not in timeout. If I use wsHttpBinding - it works without problems. Also I added logging to method I call, so I know that it even not executed.
I made all steps to configure IIS from here. The questions are:
Anybody know what the problem may be?
How can I troubleshoot/debug this
problem?
I am as frustrated as you are with this misleading fault message. If I am not wrong you get this TimeoutException within the first second. I can assure you your issue either related to security or serialization problems. I took this issue to Microsoft's WCF product group, they seemed to be surprised but didn't hear back anything.
First suggestion is to look at NetTcpBinding security settings. Make sure both client and service have identical bare bones security settings to start with (such as not message encryption nor transport layer security). If you can make it work without security, step by step increase security settings.
Second suggestion some serialization problem may be crashing the service: An empty nullable field, overloaded methods mixing with operations, ambiguous contract names, invalid casts.To debug, setup tracing in your service's config settings. You can do this easily via WCF Service Config utility(SvcConfigEditor.exe). Run your service get the exception, stop it and open the generated trace logs with WCF Service Trace Viewer Tool. Both tools comes with .NET (not Visual Studio) and can be found in Program Files/Windows SDKs folder.
I have developed a application that run on a device with Wince 5.0.
I make web service calls using WLAN. The application works fine if the app server is with the LAN.
In the other case, it raises a exception only for the first time when the application tries to communicate with the appserver. If the application is launched for the second time it does not raise any exception.
The stack trace:
Tuesday, April 13, 2010 - 10:03:04 AM:
Unable to connect to the remote server
at System.Net.HttpWebRequest.finishGetResponse()
at System.Net.HttpWebRequest.GetResponse()
at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.SoapHttpClientProtocol.doInvoke(String methodName, Object[] parameters, WebClientAsyncResult asyncResult)
at Aarya.Service.MIDServiceProxy.ManagementService.MIDAuthenticateLoginandRole(String sUsername, String sPassword)
at Aarya.Modules.MID.ProxyWrapper.ManagementServiceWrapper.MIDAuthenticateLoginandRole(String sUsername, String sPassword)
at Aarya.MID.AuthenticateManager.Logon(String loginName, String password)
at Aarya.MID.Shell.PerformAsyncLogin()
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
at System.Net.Sockets.Socket.ConnectNoCheck(EndPoint remoteEP)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Connection.doConnect(IPEndPoint ep)
at System.Net.Connection.connect(Object ignored)
at System.Threading.ThreadPool.WorkItem.doWork(Object o)
at System.Threading.Timer.ring()
My guess is that the first time it is launched you don't have a network connection. Your web service call then calls down into connection manager, which then powers up the radio, contacts the DHCP server, gets an address, then creates the network connection.
All of this process is probably taking too long and your app time's out. Once you've made the first call, Connection Manager keeps that connection open for a while and your second run uses that existing connection, so it succeeds.
Your app needs to be handling timeouts anyway (what if the network is out of range or unreachable), so proper situation handling should take care of this anyway.