Problem running pyds9 (ValueError: no active ds9 running for target: ds9)

[Akerfeldtt]

I'm having the following errors when I try to run:

import pyds9
d=pyds9.DS9()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/Sam/miniconda2/envs/iraf27/lib/python2.7/site-packages/pyds9/pyds9.py", line 451, in __init__
    raise ValueError('no active ds9 running for target: %s' % target)
ValueError: no active ds9 running for target: ds9

ds9 and ds9.zip are located:

which ds9
/Users/Sam/miniconda2/envs/iraf27/bin/ds9

This is included in my path and it's executable. I'm running this on my mac, High Sierra 10.13.2 through XQuartz.

I have XPA_METHOD=local set.

Additionally to the error, everytime I execute the line "d=pyds9.DS9()" it starts a new instance of ds9 and it stalls. Having ds9 already open when I run python does not fix the problem.

[montefra]

@Akerfeldtt , sorry for the very late answer. Do you still have the problem?

[StefanBaar]

I have the exact same problem on Ubuntu 18. pyds9 works when I ssh -X into the machine, but not if I call pyds9.DS9() from within Python in Terminal on the desktop.

[ericmandel]

This sounds like a mismatch between the XPA_METHOD value in the Python environment and the DS9 environment. You can check the DS9 value from File -> XPA -> Information and the Python value from the environment variable itself (os.environ['XPA_METHOD']). Are they the same type?

[StefanBaar]

Thanks for the quick reply.

In DS9 I get the following XPA info:

XPA_VERSION:    2.1.18
XPA_CLASS:  DS9
XPA_NAME:   ds9
XPA_METHOD: 7f000001:41927

when calling in python2:

import os
os.environ['XPA_METHOD']

I get:

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-4-8d357ffc76f7> in <module>()
----> 1 os.environ["XPA_METHOD"]

/usr/lib/python2.7/UserDict.pyc in __getitem__(self, key)
     38         if hasattr(self.__class__, "__missing__"):
     39             return self.__class__.__missing__(self, key)
---> 40         raise KeyError(key)
     41     def __setitem__(self, key, item): self.data[key] = item
     42     def __delitem__(self, key): del self.data[key]

KeyError: 'XPA_METHOD'

[ericmandel]

OK, so your DS9 is using inet sockets (listening on 127.0.0.1) and your pyds9 is using the default inet sockets too. With inet sockets, sometimes we see a long delay due to a misconfiguration of the local network, e.g., a wrong hostname. You can try setting XPA_METHOD to "unix" or maybe "localhost" in both the environment running DS9 and the environment running Python, and see if that fixes the problem. Setting XPA_METHOD in this way bypasses the hostname processing (where the ip of the hostname is looked up and used for the socket connection), so if there is a misconfiguration, it will be ignored.

[StefanBaar]

Thanks again for the quick reply. I don't think I have any hostname or local network issues, since using pyds9 remotely through x11 works great.

However, I still haven't resolved the issue when running pyds9 locally in a terminal on the desktop. I am still getting the error:

d = pyds9.DS9("CCDIMAGE")
ValueError: no active ds9 running for target: CCDIMAGE

I have set the XPA method in ds9 and the os environment to the same value.

In [1]: import os
In [2]: os.environ["XPA_METHOD"]
Out[2]: '7f000001:45035'

However, still no luck. However, it sometimes works if I open ds9 before running pyds9.

[ericmandel]

Did you try setting XPA_METHOD to "unix" in both environments? I'll assume so and we can move onto the next guess ...

... which is to try starting up the xpans name server manually. Usually this is not necessary: xpans should start automatically when needed. But your problem is consistent with xpans not being ready when needed.

(Starting xpans manually and leaving it running forever is perfectly acceptable. In the days when I was involved in DS9 development, I always ran xpans manually. So this is not a trick, just a different way of doing things.)

In any case, you have two options:

1. You can find the xpans program that was built and installed in your Python install directory. I have no idea where that gets stored, Python is just a big mystery to me.
2. You can clone the XPA source code from https://github.com/ericmandel/xpa and build from source in the usual way, something like:

   ./configure --prefix=$HOME
   make
   make install

   Once you have a working xpans located, just start it manually this way:

   xpans &

   making sure that the XPA_METHOD variable is the same for all programs that will use XPA.

Then try starting pyds9 and see if this fixes things.

[StefanBaar]

Ok, I have xpans and started it. However, it did not resolve the issue. I have been digging a little through the pyds9 code and figured out, that the above mentioned error (ValueError: no active ds9 running for target: CCDIMAGE) has probably nothing to do with pyds9.

The problem is probably with the aqua (or what ever is used on ubuntu ) version of ds9.

What I found out: When accessing the terminal from the desktop: When trying to open ds9 through pyds9 or the python xpa module with the currently set XPA_METHOD of ds9, xpa while return nothing. On top of that, on the next start of ds9 the XPA_METHOD will be reset to a different value. :-( still I get: ValueError: no active ds9 running for target

When accessing the terminal via remote ssh: Everything works. Even if ds9 is open or xpans is not running.

Question: How can I tell ds9 or pyds9 not use the x11 version ds9 and not the aqua version?

I had similar issues on Mac. But for Mac the two versions (aqua and X11) can be downloaded individually. Therefore one can just run the x11 version and does not run into trouble. http://ds9.si.edu/site/Download.html

[ericmandel]

Sorry, I may not have explained things well enough. The valid values for the XPA_METHOD environment variable are:

inet unix local localhost

where:

-- inet means use internet sockets -- unix, local mean use local (file) sockets -- localhost means use only the 127.0.0.1 localhost

By default, the XPA_METHOD is inet, so regular internet sockets will be used to communicate. The actual value shown by DS9 changes, because the value is a combination of the ip address and port that DS9 is listening on (and the port changes each time you start up DS9):

XPA_METHOD: 7f000001:50278

Here the ip is 7f000001 (which translates as 127.0.0.1 in the usual form) and the port is 50278. If you start another DS9 the ip should remain the same but the port will change. In sum, I am not surprised that DS9 -> File -> XPA info is returning a different value each time its run.

Also, to my knowledge, there is no Aqua version of DS9 under Linux, only an X11 version. So I am not sure what you mean by the Aqua version under Linux.

However, you make a good point: if you have more than one version of DS9 running, perhaps you are picking up an old or somehow bad version. This is simply a question of which version of DS9 is found in the PATH first when pyds9 tries to start it up. You might be able to find this out via ps:

  ps guwax | egrep -i ds9

If you installed xpaget, you can find the path directly:

xpaget ds9 -env PATH

[StefanBaar]

Thank you very much for explaining. That makes everything a lot clearer.

I totally misunderstood

I appreciate the help. That solved the problem.

[ericmandel]

OK, that's great, if you think we are done, should we close this issue?

[StefanBaar]

Yes, I think we can close it now. Everything was explained in great detail. Thank you very much again.