I have PuTTY installed and I can successfully log in to the remote host. I also have Xming installed on the same host running PuTTY. The remote host is running Ubuntu 12.04, and by default, localhost is set to in the /etc/hosts file. When I log in, the DISPLAY variable is correctly set to localhost:10.0, but for some reason, X applications are unable to open the display:

[user@host ~]$ xeyes
Error: Can't open display: localhost:10.0

However, if I set the DISPLAY variable to, then X11 is successfully forwarded to Xming. If I change localhost on the Ubuntu box to resolve to, it works, but a heap of other applications suddenly become very slow, even after a reboot. So this isn't a solution for me.

What I want to know, is what is listening on instead of Is it X? Or SSH? How can I force whatever it is to resolve localhost from /etc/hosts rather than assume it is According to Wikipedia, applications are allowed to make that assumption, but in my particular case it is causing me problems! Alternatively, how can I customise the DISPLAY variable so it is automatically set to on login?


Create an alias in your .bashrc / .bash_aliases (depending on how your login resource files are set up):

alias x='export DISPLAY="$(echo $DISPLAY | sed '"'"'s/.*:\(.*\)/\1/'"'"')"'

And then type x on logon.

(Note this handles the fact that for each new request for X forwarding made to the SSHD on the remote host the number assigned to your X session is incremented, so it may be :10.0 or it may be :11.0 etc).

You can put the export command in your .login, but that will effect ALL logins not just those made from putty.

EDIT: The OP has asked why this works. I would assume that you have an alias on your loopback device of the address, and the standard loopback address as the main interface address (an ifconfig would confirm that). Most loopback devices will default to a netblock and therefore routing will be in place to point that /8 via the lo device: dev lo  scope link 

localhost (as you've already pointed out) resolves via your /etc/hosts and points to that address, and therefore that's the IP most services will use. You may be able to change it to resolve to, but that would probably also involve restarting all your services that utilize the address (netstat -an will show these) after you have changed it in your hosts file.

|improve this answer|||||
  • While this rectifies the issue, it doesn't help me understand why it is happening in the first place. – dreamlax Aug 1 '13 at 5:25
  • @ekaj: I've removed those question marks. – Drav Sloan Aug 1 '13 at 9:57
  • @dreamlax I've attempted to answer the question (with the information you have), which has involved some guess work. – Drav Sloan Aug 1 '13 at 9:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.