This project has moved and is read-only. For the latest updates, please go here.

Cannot attach to remote process on linux machine

Feb 24, 2014 at 5:09 PM
So, embarrassingly when I try to attach to a process running on a linux server (I've tried two) I can't attach, even if I temporarily flush the firewall on the linux machine and turn the Windows firewall off.

I follow the tutorial: make a python project, install ptvsd on the linux machine (I used pip to do that on one, on the other just transferred the ptvsd folder from C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\Python Tools for Visual Studio\2.0 right across. I then set the script going on the linux server and try to attach to <secret@<remoteHostname>:5678 and it hangs for a bit and then says "could not connect to remote Python process at '<remoteHost>:5678'. Make sure that the process is running and has called ptvsd.enable_attach()"

I am somewhat at my wit's end as I've checked that enable_attach is called and is running (ps -U <username> gives me "20355 pts/0 00:00:00 python2.7"); it doesn't make any difference if I temporarily run iptables -F on the remote host and turn off the windows firewall on my local machine. Is there some extra configuration I haven't done? I'm using Visual Studio 2013 Professional at my end and I downloaded the recommended version of python tools last week; the remote machines are RHEL5 and Fedora Core 17 (as I recall) and the RHEL5 machine only has 32-bit python 2.7 whereas the FC17 machine has 64-bit python3.3 (both of which I have on my Windows machine as well and can run python projects through VS locally).

Sorry for the bother; I can get remote cross-platform debugging to work in Eclipse with pydevd from this same machine, but I'd far rather use Visual Studio if at all possible.
Feb 24, 2014 at 5:37 PM
One big difference between ptvsd and pydevd is the direction of connection - with pydevd the debugged process connects to the debugger, with ptvsd it's the other way around. So if the remote machine is behind NAT, a separate firewall etc, it is possible that pydevd would work while ptvsd would not.

Can you connect to it manually from your Windows machine using telnet? The protocol is binary, so you won't be able to do much there, but it should at least be possible to tell whether the TCP connection can be established on the most basic level...

One other thing. You mention that you're using the "recommended version" - would that be 2.0 RTM? And when you deployed ptvsd on the target machine, did you copy it over from your PTVS install, or installed it using pip? If the latter, be sure to check that you have a matching version, since there's one for 2.1 alpha on pip now, and it's not compatible with 2.0. A plain pip install ptvsd should give you 2.0 though, the only way to get an alpha is to explicitly specify the version.
Marked as answer by adamMB on 2/25/2014 at 2:08 PM
Feb 24, 2014 at 8:11 PM
Yes indeed, the pydevd thing not only runs the other way but you need to complete a map of paths on the windows machine to the linux machine, which is part of the appeal of doing it with VS (but mostly it's because VS is my favourite IDE).

Version is 2.0 RTM and the pip install was the matching one.

However there is some progress (thanks to you!). I was able to get it to work with one machine after telnetting, which when there was a Python process running the ptvsd gave me back the PTVSDBG (then a couple of binary characters). Going to chase things up with the admin of the other machine (the one I got it to work on is a VM I run myself, so I was able to tinker with the firewall).

So, provisionally this looks fixable and many thanks for your help. I'll mark it as answered tomorrow if things work on the other one as well (permissions are ever the problem with doing anything interesting...).
Feb 24, 2014 at 8:25 PM
Great to hear!

If you can get it working, and find that it is something that sounds like it could be a common issue, especially if it's out-of-the-box setting for the distro that's on the machine you're trying to remote to - please share your recipe here for the benefit of other users who may also run into it. We're testing mostly on Ubuntu as it's the most popular one by a large margin, but that also means that we might miss common problems on other distros.

If I had to guess what else it could be, since you've already tried resetting iptables locally, I'd also check if it's a SELinux-enabled distro which has restrictive socket policies.
Feb 25, 2014 at 12:15 AM
The errors were both connection permissions and both different; in the one case, as a veteran of older Red Hat distros, I didn't realise that FC now doesn't use iptables but rather firewalld (although it still has iptables there, so you can -F then and convince yourself you're doing something useful!), so my tinkering achieved naught. In the other case, the port seemed to me not to have been opened as requested and the institution hosting the server also has ACLs set at the perimeter, which I was outside; with the port opened tests from on-campus worked.

What I have done that's sort of interesting is to use PuTTY to tunnel the connection to the machine on the other side of the ACLs, avoiding the problem they were causing, which has worked pretty well so far.
Feb 25, 2014 at 10:14 PM
OK, this seems to be working fine now. Problems were largely of the PEBKAC variety, alas. I've marked the first reply as the answer.

One thing I would say is that the documentation, at least as I read it, implied that you'd either use enable_attach or wait_for_attach but that's not the case, as if you want the script to wait for you to attach the debugger (without putting a pause in for manual input just to stop things from running before the debugger is attached) -- which I need to do as my scripts run on-demand -- you use both. Re-reading the documentation, though, that's not actually implied so although it might be clearer, I would also have benefited from being a little cleverer.

Thanks very much for your help (and reminding me that no matter how far we go, telnet is still a useful connection debugging tool!). This is a really great product.
Feb 25, 2014 at 11:35 PM
With respect to unclear documentation on ptvsd functions, are you referring to the wiki page in the documentation section here on CodePlex, the video walkthrough, or docstrings in the package itself?
Feb 25, 2014 at 11:47 PM
Sorry, the documentation section here on codeplex, on this page

I wouldn't say that the documentation is unclear so much as that it was unclear to me. Others may well do substantially better!
Feb 26, 2014 at 12:27 AM
After re-reading it myself I definitely see where the confusion is coming from :) I've updated the page to make it unambiguous. Thanks for reporting this!