Ds9 communication via XPA

ds9
xpa
Tags: #<Tag:0x00007f7f6e009318> #<Tag:0x00007f7f6e0091d8>

(Merlin) #1

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.

  1. If you have a line in your .bash_profile or similar saying export 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.

  2. 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.

  1. 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.

  2. If that didn’t fix it, re-edit your /etc/hosts/ file, with computer-name on the first line replaced this time with the value reported by uname -n.

Repeat step 3) to see if that fixed it.

  1. If that didn’t fix it, re-edit your /etc/hosts/ file, this time with computer-name.local on the first line instead, i.e. taking the output of uname -n, appending .local to it.

Reboot and see if that worked.

  1. 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. :expressionless:

  2. 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 :pensive:


Using an lsst-dev stack w/ local ipython & ds9 tutorial