I have a python project located on Linux server that I want to remote debug from Windows IDE.
I’ve followed all instructions to setup remote debugging and all pieces seems to be in place and IDE can connect to remote Linux server.
However I couldn’t find an answer anywhere in docs - do i need to have a local copy of source code as well?
This would be a major obstacle and won’t work for anything but very simple projects. It’s impossible to duplicate platform-specific set of libraries on a different platform.
But there is no answer anywhere on how can I actually start “seeing” remote server’s source code in my local Windows IDE?
Hi, yes, you will need a local copy of the source code on the remote target. Komodo does not support “true remote debugging” in the sense that it will send source code over the wire too.
Since Python code is portable between platforms, I have a hard time seeing how having a local source copy can be a “major obstacle”. (e.g. remote-debugging large Django projects works fine.) Care to elaborate?
Well, I copied initial source code locally and with all the remote debugging and connections established - I got error at the very first “import NNNN” line. Than NNNN library exists within Python install on a remote server but does not exist locally.
I though - if that is remote debugging - then import will run against Python library on the remote server?
But it seems the code wanted to do “import” against local repository.
Yes, you are correct. Are you sure you’re still initiating the debugging session from the Linux server?
The only reason you need the local copy of the files is to be able to edit the file you’re debugging. Any option that some people use is mounting the remote file to a local drive/folder then use a Mapped URI. Then you’re actually editing the file being debugged, not just a local copy.
I assume you are starting the debug server remotely and having Komodo connect to it, and the you are not pressing the “play” toolbar button or running “Debug -> Go” locally.
Is there a particular reason you’re using the proxy? You don’t need it in a basic, single developer dev environment.
Also, the proxy isn’t language specific. It can be used with any of the supported remote debugging languages. It just happens to have been written in Python 2.
Can you explain a little more about your setup? I can’t understand why you would need to do this. I thought you already had a working remote debugging setup.
Sure,
As I understand the headless server where the code is running needs to connect to desktop with Komodo IDE.
Due to server-to-desktop firewall issues - the connection in this direction cannot happen.
Desktop-to-server - can.
So this cannot work:
[Linux server-with-code] —>-- [Windows desktop with IDE]
So as far as i understood - this is the only way remote debugging could work:
[Linux server-with-code] —>--- [:9000 Linux server for proxy-ing :9001] —<----[Windows desktop with IDE]
At proxy server side I ran:
./pydbgpproxy -d blackbox:9000 -i blackbox:9001
INFO: dbgp.proxy: starting proxy listeners. appid: 3668
INFO: dbgp.proxy: dbgp listener on blackbox:9000
INFO: dbgp.proxy: IDE listener on blackbox:9001
At IDE side, I setup remote debugging via proxy in Preferences->Debugging->Connection->[x] “I am running a debugger proxy …”
“Current Connection Status” reports: “Debugger Listening”=“Yes”
At my server with python code side, I type:
py3_dbgp -k DEBUGKEY1 -d blackbox:9000 my-file.py
This immediately terminates.
At proxy side I see:
INFO: dbgp.proxy: connection from 192.168.0.222:47152 [<main.sessionProxy instance at 0x7f9fabfb1bd8>]
WARNING: dbgp.proxy: No server with key [DEBUGKEY1], stopping request [<main.sessionProxy instance at 0x7f9fabfb1bd8>]
INFO: dbgp.proxy: session stopped
It seems that IDE does not connect to proxy - but there is no indication of that fact at IDE side.
I also did not find any reliable way within IDE to reset/refresh connection to proxy.
PS: At some point above setup managed to work after I restarted everything - however when I executed first line of my python script, in “Output” window I got: “ImportError: No module named ‘NNNN’”.
That module is present on remote server but is not present in my Windows IDE machine.
So clearly even when all connections (to proxy etc) for remote debugging seems to work - the code was just being executed within my Windows IDE and NOT at remote server.
I didn’t find an obvious way to tell IDE to execute the given file remotely vs. locally and to confirm which way debugging is happening.
So at some point, step #3 worked? (It did not terminate immediately?)
As for your commont on not being able to find an “obvious way to tell IDE to execute the given file remotely vs. locally”: your step #3 initiates the debug session and Komodo should pop up with a dialog with a message mentioning that a remote application is trying to connect to Komodo. That way you know you’re remote debugging.
If you get an error in Komodo’s output window that an imported module cannot be found, but running the same script on the server does not produce the same error, then I’d guess you are somehow debugging locally, which you don’t want obviously.
Your setup is quite unorthodox to me, so it’s a bit difficult to wrap my head around it. I very much appreciate your patience and for bearing with me and my dumb questions.
When I run: py3_dbgp -k DEBUGKEY1 -d blackbox:9000 my-file.py
on a remote server, I do not get any messages that anything is trying to connect to Komodo.
Komodo is suppesedly connected to proxy and py3_dbgp is connected to proxy.
So as i understand - proxy manages information flow - but i do not see any signs of this happening at Komodo IDE side.
I’d be happy to try something else, but my Linux server with code cannot connect to Komodo Windows IDE directly due to firewall issues.
This likely means that Komodo isn’t connected to the proxy. Confirm Debug menu > Listen for debugging session is selected. From your step by step notes above, you really gloss over step 2 which is a really important step and is what the error above is pointing to, a mis-configured Komodo.
Successful connection output from proxy, starting with my IDE connecting at line 4 and then the sample app connecting at line 5 and a debugging session starting in Komodo:
INFO: dbgp.proxy: starting proxy listeners. appid: 27371
INFO: dbgp.proxy: dbgp listener on localhost:10001
INFO: dbgp.proxy: IDE listener on 10.19.0.148:10000
INFO: dbgp.proxy: Server:onConnect ('10.19.10.91', 55618) [proxyinit -p 10000 -k careyh -m 1]
INFO: dbgp.proxy: connection from 127.0.0.1:58908 [<__main__.sessionProxy instance at 0x27dc8c0>]
So even though we are getting through identical steps with identical confirmation steps - my setup refuses to do “remote” debugging and tries to execute code locally.
PS: Drive M: on Windows is mapped directly to /home/p3 on remote Linux box.
PPS: While I am looking at “Import error” - proxy blows up with this message:
If I’d want to recreate “working” connection again - I’d have to close everything and restart everything from scratch.
And then it would “work” only for the first time - and still with local debugging. Never with remote debugging.
Based on your configuration above, if the request to debug reaches Komodo then a dialog will appear asking if you want to allowed a remote debug session to start. Prefs > Debugger: When receiving a remote debugging connection. So you should click “Ok” I guess.
To clarify, Komodo “listens” for a debugging request from an external source. That is your running application on the server. In your case the proxy you’re using forwards the request from your app to Komodo which is listening to the specific host:port of your proxy.
As I said above, you should start with the most basic setup so you know what it’s supposed to do. I was able to get it working so it should be working for you. Now you need to pull pieces out and figure out what’s breaking, whether it’s your code, your setup, or Komodo itself.
In one of your screenshots you noted that your proxy “blows up” with an error. That error looks to be a timeout. I’m guess you haven’t clicked “Ok” to the remote debugging request and the process is just hanging and therefore times out and crashes.