This article relates to local copies of ds9 communicating with either a remote or a local stack - it should fix XPA communication issue with either. Remote setup instructions can be found here.
There have been several instances of people failing to get local copies of ds9 to receive data via XPA, and worse (/weirder), instances of people’s working systems seemingly spontaneously stopping working in this regard, apparently without updating changing/anything. Not cool.
If, when you start ds9, you get a box popping saying something like: XPA unable to verify hostname, setting XPA_METHOD to LOCAL
then you’re likely one of these lucky people. Even more luckily, you’ve found this page, which has a non-zero chance of helping, yay!
Robert’s infinite wisdom has led to a diagnosis, and fixing this problem on at least two machines now. The steps (that worked for these machines at least), were roughly as follows, hopefully this will help a few people out. The following is a heuristic, iterative procedure which likely contains unnecessary steps, so dot around as you like, but if you don’t really understand what this stuff is doing I suggest just following it as written.
-
If you have a line in your
.bash_profile
or similar sayingexport XPA_METHOD=local
(or the equivalent for your shell), remove this. Note that, if you’re suffering from this communication problem, but weren’t seeing that box pop up, this was likely stopping that happening, so you’ll now probably see that box until the rest of the fix is finished. I mention this as it’s not a real regression, just some more symptoms showing through. -
Edit your
/etc/hosts
file so that it reads:Host Database
localhost is used to configure the loopback interface
when the system is booting. Do not change this entry.
127.0.0.1 computer-name.local
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
where computer-name
is found out (on a Mac) by going to ‘System Preferences --> Sharing’ and then not pasting the contents of the ‘Computer Name’ box, but taking the sanitised string underneath the box which follows the “Computers on your local network can access your computer at:” text. Make sure to include the .local
at the end.
-
Reboot and see if this fixes things. Yes, reboot. It shouldn’t be necessary, but seems to be (sometimes). Just pretend you have a Windows machine if that helps.
-
If that didn’t fix it, re-edit your
/etc/hosts/
file, withcomputer-name
on the first line replaced this time with the value reported byuname -n
.
Repeat step 3) to see if that fixed it.
- If that didn’t fix it, re-edit your
/etc/hosts/
file, this time withcomputer-name.local
on the first line instead, i.e. taking the output ofuname -n
, appending.local
to it.
Reboot and see if that worked.
-
If you’re still reading, you’re in a bad place, and this is unlikely to do anything, but hey, the sunk-cost fallacy means you probably feel like you might as well try this, but now we’re really guessing. Try going to ‘System Preferences --> Sharing’ and enabling Internet Sharing (and tick a box on the right to share over some port, so that it’s not a no-op), and then go back to step 2) and repeat up to here. If you end up back here then you’re out of luck I’m afraid. Oh, you could also try also adding an
export XPA_METHOD=localhost
to your env, this might help, who knows… If you do that you should probably also repeat all the previous steps as well. -
If you made it this far, try installing
xpra
instead. It’s not going to be as responsive as having a local copy of ds9, but it’s better than most x-forwarding things. And sorry for wasting your time