cannot export DISPLAY to workstation from server

[Mark Vollmers]

Hi, all. I've got a question here. I have been exporting the display for my server to my workstation for some time now with no problems. I have the xhost + defined in my profile, so it runs everytime I log into the workstations. I telnet to the server, and type export DISPLAY=pro2:0.0 and then run the app (like sam). Now, it doesn't work. It gives me an error:
XI0: fatal IO error 232 (Connection reset by peer) on X server "pro2:0.0" after 14 requests (13 known processed) with 0 events remaining

I have had no problems in the past. Yesterday, I hooked an UPS to the workstation and installed Powerchute on it. I have removed powerchute, but it still does the same thing. I have gone to another workstation, and that works fine. What does the error mean, and what has changed on the workstation that is preventing this from working? How do I fix it? thanks in advance!

Mark

[Patrick Wallek · Accepted solution]

Mark,

Found this in the TKB. Don't know if it'll help but here it is.

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=f969c7df09eabbda3d/screen=ckiDisplayDocument?docId=200000048972696

[Mark Vollmers]

After a little more looking, here is what I have found.

sam and stm give me the error
xpowerchute (a GUI interface for powerchute) does not give an error, but does not open either. It sits for a long time and then returns a prompt. Does not show with ps -ef
xclock hops right up there.

Wierd, huh? I'll check the network cable, but any other ideas?

Mark

[A. Clay Stephenson]

Hi Mark,

I somehow think this is an IP address resolution problem. Humor me and set the DISPLAY=10.1.1.11:0.0 or whatever and try it.

Clay

[Mark Vollmers]

Sorry, Clay, no go. Set the display using the IP address, but it still hangs.

[A. Clay Stephenson]

Hi Mark,

Okay I admit I'm grasping but I've had one other thought. Is it possible that the Powerchute install mangled the /etc/services
file (or if this is NIS the services map)?

Clay

[John Poff]

Mark,

At times like this it might be worth expanding on Clay's last answer and try to find out what all has changed. I'd do a find on every file that has changed since you installed the APC software. You might find the culprit in that long list. Just a thought.

Good luck!

JP

[Bill McNAMARA_1]

Seems to me that the workstation is connecting the display, I see 13 Xlib requests processed.
Usually the first is XOpenDisplay.

You might want to make sure that the Workstation can load fonts.. can you launch apps locally on the workstation?

Try xclock which is more or less just graphical X and no fonts.

I would suspect that your DE is missing something.

Can your run xscope/xplay from
http://www.hp-uxconsulting.com/hpux/x11/xscope.html
and post up the xscope output.
I'll identify exactly where the problem is.

Later,
Bill

[Mark Vollmers]

Clay- I looked, and the modification date for /etc/services (via a ll) was June 10th, so that wasn't it.

Bill- I tried to get xscope to run, but I'm having some problems. I'm a little confused, since I only have one server. I unzipped it and ran the xscope command on the server, using the workstation IP address, but the command just hung there and did not give me a prompt back. I ran SAM after exporting the display on another dterm window, and the same thing happened, and nothing was written to the zscope temp file. What am I doing wrong here?

I have noticed some stuff in general: xclock works fine. SAM, stm, swinstall and xpowerchute (from the server) do not work, although they all did before. On the workstation, I keep getting a bunch of errors saying the the NFS server munix is not responding (in the syslog) and then a note to the prompt saying that the connection has been re-established. It seems a little slow, in general, when using telnet. I guess I am still leaning on network connections (don't have the network cable yet; our windows admin makes them).

Mark

[Bill McNAMARA_1]

I can only assume the problem is fonts.
Can you use xset -q
to see your font path.

You display is working fine. There is no problem there... proven by xclock running.

Setting a font path can then be easy enough, make sure xfs is running on one of your servers:
/sbin/init.d/xfs start
and on the workstation display xset fp+ xfservername:7000


Regarding xscope I know it can be run with only one server but never figured out how to do it! It's an mit tool that is used to sniff and redirect the xprotocol that is travelling over the network.. nettl will do the sam but it's a nightmare to read those logs.
See:
http://www.hp-uxconsulting.com/hpux/x11/nettl.html for more on that.


On xscope it trick around with the display envvariable and one server, the one running xscope is the one that the application is running on. Xscope then sends the Xprotocol received to the final display.

server_1> export DISPLAY=myfinaldisplay:0.0
server_1> xscope -h -i1 -o0 -d0 -v3 > /tmp/xscope_trace


server_2> export DISPLAY=server_1:1
server_2> sam

SAM then displays to server_1:1 which is where xscope is running. Xscope then reads input on display :1 (-i1) and outputs on IP:0 the finaldisplay.

The log then gathers.
For this method you need 2 servers and your final display.

LAter
Bill

[Mark Vollmers]

Bill-
I looked at the font path, and a bunch of stuff was there (like a dozen and a half paths listed there, all /usr/... or /opt/...

I swapped out the cable, and it seems to be behaving normally. I guess I must have yanked on it by mistake or something when I put in the UPS. I'm gonna keep an eye on it, though. I think I'll add the font path that Bill suggested, though, just to be sure. Thanks for the help, everyone.

Mark

[A. Clay Stephenson]

Hi Mark,

That must be a highly selective cable to allow xclock packets through but keep SAM packets out. I'm skeptical that you have found the problem but I hope so. It may have been that removing the cable forced a reset of the LAN drivers and that fixed your problem.

Good luck, Clay

[Alex Glennie]

Interesting .... xclock not use fonts , sam gui will

anyone checked in the fonts directories 2 files of importance : fonts.dir and fonts.alias any of these zero bytes : be on the safe side and use mkfontdir to recreate : see man page.

whats the X interface on the W/S CDE ? if so just do the above wrt CDE's fonts dir.

check dr_dt output, var/dt/Xerrors syslog.log and $HOME/.dt/error & startlogs for more clues ..... very bizzare ! the error gives us little help :(

[Mark Vollmers]

I don't know if this is actually the case (or even if it could work), but I wonder if the cable got hosed just enough to allow a small amount of data through (like xclock) but hung up when a large amount tried to move (like sam). Maybe I'm just dreaming. I think I'll have to spend some quality time with the workstation here and maybe I'll stumble across something. Then again, maybe I'll just nuke it and start over. It would be a good exercise, right? :)

Mark

[A. Clay Stephenson]

Hi Mark,

I don't think the cable is it, but I can put my physicist's hat on and give you one explanation which fits the observed data. I think what happened is that your duplex/speed settings were mismatched between your workstation and the switch. Small amounts of data APPEAR to work but larger amounts timeout.
When you pulled the cable, the reset properly negotiated the speed/duplex and all was well. I would hard set the duplex/speed on both end (no auto-negotiate); auto-negotiation is not always reliable.

My 3 cents worth, Clay

[Mark Vollmers]

Clay-

You could be right there. Everything was set up when I got it, so I don't know about the values. In fact, I know nothing about network speed setttings. Where do I look for those (both server and workstation) and what is a good value? Or do they just have to match? Ah, it's fun to chart new territory... Thanks!

Mark

[A. Clay Stephenson]

Hi Mark,

You disn't mention what OS or even if your workstation is unix based or windows. If windows you go the the Network Drivers dialog box and look for the settings. On unix boxes you use the lanadmin command to check the settings. You may also need the lanscan command to identify the 'NMID' if you are running 10.20. Man lanscan and lanadmin for details. Lanadmin can be used to set the speed/duplex 'on the fly' but to make the changes occur on each boot you will need to
edit files in /etc/rc.config.d. I don't know what hardware you are running but the configuration files will be something like 'hpbtlanconf', 'hpetherconf', 'hpbase100conf', 'hpgsc100conf', etc.
The good news is that all are commented so that you should be able to see what to do.

For the switch end, your network admin will have to assist you.

If you can, hard set to 100FD (not all cards support 100FD); next best is 100HD. The important point is that both ends of any connection must agree. It is perfectly fine; however, that the server to switch connection run at 100FD while the workstation to switch connection run at 100HD or even 10HD as long as both ends of any single link agree.

Hope this helps, Clay

[Mark Vollmers]

my bad. workstation is 10.20, and server is also 10.20 (although I'll be hopping that up to 11.0 one of these days). I'll poke around in the files and get try to get everything matching. Hopefully, there will be no hiccups. Thanks, Clay!

Mark