SCIENTIFIC-LINUX-USERS Archives

August 2009

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Devin Bougie <[log in to unmask]>
Reply To:
Devin Bougie <[log in to unmask]>
Date:
Fri, 28 Aug 2009 10:56:51 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
Hi, All.

In our control room, we use XDMCP on SL4.4 to log into a variety of  
control system Alphas running OpenVMS 8.3 (update 8), with Multinet  
TCP/IP v5.2.  This has worked very well for the past few years.

As of about three weeks ago, we started seeing X sessions being  
killed, typically a few 10s of seconds after they connect to the VMS  
system and present the VMS XDM login screen.  When this occurs, the  
session quietly ends without any error messages, regardless of whether  
or not you actually log into the VMS system.  While the linux systems  
all behave identically, the problem seems to shift around between VMS  
systems.  For example, yesterday morning no linux systems were able to  
remain logged into cesr28, while in the afternoon cesr28 was fine but  
the problem had shifted to cesr27.

The problem has been seen both with Linux display systems and with NCD  
X terminals.  When it happens with the NCDs, they generate a popup  
menu asking if the session should be killed, giving the user the  
ability to remain logged in. The Linux display systems, however,  
simply kill all the windows and redisplay the XDMCP chooser. We have  
not found any option on the linux side to prevent this.

For reliability, we have all updates disabled for these linux  
systems.  As the linux xterms have not changed since their deployment  
several years ago and this problem first surfaced roughly three weeks  
ago, it seems as though the linux systems are sensitive to something  
that is happening on the VMS side or on the network.

We have been testing this using the gdm chooser and, for example, the  
following command:
/usr/X11R6/bin/X -ac -once -query cesr27

If anyone cares to look, I can send the packets captured during both  
successful and failed sessions using tshark.  We have also started a  
thread in the HP IT Resource Forum:
http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1362175

Any suggestions for fixing this problem would be greatly appreciated.

Many thanks,
Devin


------
Devin Bougie
Laboratory for Elementary-Particle Physics
Cornell University
[log in to unmask]

ATOM RSS1 RSS2