Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When SSH'd locally into my computer (don't ask, it's a workaround), I can't start graphical applications without running:

export DISPLAY=:0.0

If I run this first and then run a graphical application, things work out. If not, it doesn't work, there's no display to attach to.

Is there a command for listing all available displays (ie: all possible values) on a machine?

share|improve this question
A cleaner way to launch applications from a terminal is ( DISPLAY=:0 yourapp & ). – nobar Feb 1 '12 at 0:03
To get that display number from a command line script, try w. More info: list existing X display names? – The Sexiest Man in Jamaica Apr 18 at 18:03
up vote 51 down vote accepted

If you want the X connection forwarded over SSH, you need to enable it on both the server side and the client side. (Depending on the distribution, it may be enabled or disabled by default.) On the server side, make sure that you have X11Forwarding yes in /etc/sshd_config (or /etc/ssh/sshd_config or wherever the configuration file is). On the client side, pass the -X option to the ssh command, or put ForwardX11 in your ~/.ssh/config.

If you run ssh -X localhost, you should see that $DISPLAY is (probably) localhost:10.0. Contrast with :0.0, which is the value when you're not connected over SSH. (The .0 part may be omitted; it's a screen number, but multiple screens are rarely used.) There are two forms of X displays that you're likely to ever encounter:

  • Local displays, with nothing before the :.
  • TCP displays, with a host name before the :.

With ssh -X localhost, you can access the X server through both displays, but the applications will use a different method: :NUMBER accesses the server via local sockets and shared memory, whereas HOSTNAME:NUMBER accesses the server over TCP, which is slower and disables some extensions.

Note that you need a form of authorization to access an X server, called a cookie and normally stored behind the scenes in the file ~/.Xauthority. If you're using ssh to access a different user account, or if your distribution puts the cookies in a different file, you may find that DISPLAY=:0 doesn't work within the SSH session (but ssh -X will, if it's enabled in the server; you never need to mess with XAUTHORITY when doing ssh -X). If that's a problem, you need to set the XAUTHORITY environment variable or obtain the other user's cookies.

To answer your actual question:

  • Local displays correspond to a socket in /tmp/.X11-unix.

    ls /tmp/.X11-unix
    cd /tmp/.X11-unix && for x in X*; do echo ":${x#X}"; done
  • Remote displays correspond to open TCP ports above 6000; accessing display number N on machine M is done by connecting to TCP port 6000+N on machine M. From machine M itself:

    netstat -lnt
    netstat -lnt | awk '
      sub(/.*:/,"",$4) && $4 >= 6000 && $4 < 6100 {
        print ($1 == "tcp6" ? "ip6-localhost:" : "localhost:") ($4 - 6000)

    (The rest of this bullet point is of academic interest only.)

    From another machine, you can use nmap -p 6000-6099 host_name to probe open TCP ports in the usual range. It's rare nowadays to have X servers listening on a TCP socket, especially outside the loopback interface.

    Strictly speaking, another application could be using a port in the range usually used by X servers. You can tell whether an X server is listening by checking which program has the port open.

    lsof -i -n | awk '$9 ~ /:60[0-9][0-9]$/ {print}'

    If that shows something ambiguous like sshd, there's no way to know for sure whether it's an X server or a coincidence.

share|improve this answer

The display is the first argument to Xorg. You can ps then grep Xorg out.

[braga@coleman teste_geom]$ ps aux | grep Xorg
root      1584  5.3  1.0 156628 41708 tty1     Rs+  Jul22  22:56 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-a3kSKB/database -nolisten tcp vt1
braga     9110  0.0  0.0 109104   804 pts/1    S+   00:26   0:00 grep --color=auto Xorg

You can then awk this into wherever format you need to.

share|improve this answer
This doesn't detect displays created by a server other than Xorg, e.g. Xvnc. – cjm Jul 23 '11 at 6:37
ps aux |grep X worked better for me – nobar Feb 1 '12 at 0:00
w shows everyone who is logged-in and their display. – Plenus Franckly Nov 3 '15 at 16:48
# Show all active login shells, with displays
$ w -oush

trunc-us tty1                      23:02  -bash
trunc-us tty7     :0                4days /sbin/upstart --user
trunc-us pts/4    :0                      w -oush

# Capture the Display part
$ w -oush | grep -Eo ' :[0-9]+'


# only unique lines
$ w -oush | grep -Eo ' :[0-9]+' | uniq


# trim off the leading space
$ w -oush | grep -Eo ' :[0-9]+' | uniq | cut -d \  -f 2

[Edit: I ran an Xnest instance to see if this would catch it - it doesn't; it only captures login shells ('w' is short for 'who'). Back to the drawing board for me.] [Edit: Found it:

$ ls /tmp/.X11-unix

X0 X2

$ ls /tmp/.X11-unix | tr 'X' ':'


share|improve this answer
That's... odd... I wonder what the explanation there is. – Fordi Jun 17 at 5:02
(regarding GDM running on display 1024 for me ) I couldn't replicate it a second time. At the time I was trying out xrdp, windowed X11 forwarding and a few VNC clients. It seems that in a typical installation, GDM will run on X0... or X1 if you've hit the "log in as another user" button on the lock screen. Your second method worked for me on Fedora 23 – Ray Foss Jun 21 at 12:41

In the /tmp folder there can also be .X??-lock files with ?? indicating the session numbers.

You need to delete these if you want to re-use a session number.

You can see them using ls -a as normally files starting with a . are hidden.

share|improve this answer
Those are the display sessions? – phk Jul 3 at 10:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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