This sounds like CR 6805507: "Xorg server uses bad locking algorithm
which affects SRSS".
The bug has been fixed in 4.1 patch rev -02, but that patch has not yet
been finalized and released.
There is a workaround:
Add the following line to /opt/SUNWut/lib/utxsun, near the end (but
before the last line, which execs the X server):
rm -f /tmp/.X${dpy}-lock
However, if you apply this workaround, you must be very careful to
remove it when the 4.1 patch which addresses this problem is eventually
applied.
-Bob
Matthew Kurtz wrote:
All,
We are currently running srss 4.1 with core patch 139549-01 on the latest
release of Solaris 10x86. The following message will appear in
/var/adm/messages:
Mar 25 18:03:44 suntan utxexec[6589]: [ID 901666 user.error] utxexec ERROR:
Cannot open display :64
Mar 25 18:03:44 suntan root: [ID 702911 user.error] utxinit ERROR: X session
startup timeout, display 64
When this happens we have discovered that this error is related to sunray
dtu’s trying to connect to the nscm login screen. The sunray will show the
26B message along with the image of waiting for data from the server. The
SunRay remains at this screen until it is power-cycled. For some reason the
session that was previously using display 64 failed to exit properly and now
a sunray unit is trying to connect to that display number for the login
screen. All the end-user/sunray shows is error 26B.
Doing a more on /tmp/.X64-lock will give the PID of that display number.
When the error above happens, and you search for that PID it has typically
been reused by another process or is not in use (it is no longer associated
with any Xnewt process).
We have solved the issue by removing the /tmp/.X64-lock file (the lock file
that corresponds to the display number in the error message) and
power-cycling any sunrays that have hung. If the lock file is not removed
we have noticed that any sunray's attempting to pull up the nscm login
screen on that server will hang in the same manner (even the unit that was
power-cycled if it connects back to the same server). Does anyone know what
may be causing this issue? It can turn into a large problem real quick if a
large number of people lock their screens at the same time before that bad
display file can be removed. Units that already have a properly attached
nscm login screen, or units attached to other servers, are not affected.
Thanks
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
