X display not working anymore

[Vladimir Fabecic]

What happens when you do:
# xclock (not "xclock &")
Is there an error message?

[Steven Schweda]

> What happens when you do:

If DISPLAY points to the wrong
host:server.screen, who cares what the error
message might be?

[Vladimir Fabecic]

And what if DISPLAY does not point to the wrong host:server.screen?
Anyway, it can also be a permission problem (OK, I do not think so, but ...) or env problem (PATH).
Error message may help.

[Danesh Qureshi]

I tried to change the DISPLAY to 0.1 but I still cannot get any X application to work.

If I type xclock only, nothing happens. I get returned to the shell prompt straight away without any error message. It is very odd there is no error message after I type xclock. If I run "xclock &" I did not see any xclock process when I use "ps -eaf | grep -i xclock" to check for it. Normally, you would see background process of xclock.

See output below of xclock command.

lysithea$ xclock
lysithea$
lysithea$ xclock &
[1] 16470
lysithea$
[1] + Done xclock &
lysithea$


As I mentioned if I run xclock from the main Tru64 Unix console I see it appear on the screen.

I will reboot the server which been running for 448 days. May be rebooting may fix it.

The server was fully patched to patch kit 6 almost two years ago.

[Steven Schweda]

> And what if DISPLAY does not point to the
> wrong host:server.screen?

Good point. Perhaps black really is white,
and up really is down. But I doubt it.

The info from the questioner is vague and
incomplete, but, as I understand / assume /
conjecture what's happening here, lysithea =
lysithea.mdx.ac.uk, and that's the Tru64
system, not the laptop with the X server.
So, I conclude that any DISPLAY which uses
lysithea:0 for its host:server part must be
wrong.

I don't have a laptop running Exceed, but I
do have a Sun Solaris workstation, and when
I use "ssh -X" to connect from it to another
system, I get results like the following.

To a Tru64 system:

sol> ssh -X urtx
[...]
HP Tru64 UNIX V5.1B (Rev. 2650); Mon Feb 19 11:57:07 CST 2007
No mail.
urtx> echo $DISPLAY
urtx.antinode.info:10.0

To an HP-UX (11.11) system:

sol> ssh -X dy
[...]
Value of TERM has been set to "xterm".
dy $ echo $DISPLAY
10.0.0.39:10.0

where 10.0.0.39 is the IP address of "dy",
the HP-UX system.

So, I conclude that a typical sshd sets up
a virtual X server at server_host:10.0 (and
it even seems to work around here).

The questioner reported that his DISPLAY was
"lysithea.mdx.ac.uk:0.0". To me, this does
not appear to be consistent with his claim
that he had "set the X11 tunnelling with
[his] ssh session". Based on the results of
my tests, I'd expect it to be something like
"lysithea.mdx.ac.uk:10.0".

I've tried to guess who set DISPLAY to the
reported value, but so far I've learned
nothing about it. My guess is still that
it's something in the user's shell start-up
script(s), but my psychic powers are too weak
to tell me more.

I have code in my own "~/.profile" which
looks at the output of "who am i", and uses
it to set DISPLAY, but it's inside a test
like this:

if [ -z "$DISPLAY" ]; then
[...]
fi

so, if someone else (like, say, sshd) sets
DISPLAY for me, I don't whack its (good)
DISPLAY definition with my (bad) DISPLAY
definition.


> May be rebooting may fix it.

The X Window System is not Microsoft Windows,
so I doubt it.

[Danesh Qureshi]

The xclock problem has been solved.

The xclock file in the /usr/bin/X11 directory was empty i.e. zero blocks and the creation date of the xclock file was 31st Jan 2008.

I dont know how xclock file got to be in
this state.

I've copied xclock file from another Tru64 unix system to this one.

Now xclock appears on my laptop fine.

Thank you to everyone for their help.