I should mention that the fix for 6573728 will also
be included in the release of SRSS 4.0 (included
in SRS 4 Update 2), scheduled to appear on Sun's
Download Center on Aug 21 (non-English versions
of the product are scheduled for Sep 14).
-Bob
Bob Doolittle wrote:
Matthias Ernst wrote:
Emilio Valencia wrote:
Hi,
I've SunRay Server 3.1 + patches on Solaris 10 11/06.
Sometimes, after I unlock screen inserting my card and session password
i get unlocked for 2-3 secs. and after that I get blank screen.
At this moment I can change workspace with CTRL+ALT+CURSOR and show
workspace window but rest is black. If i press CTRL + MOON I can get a
"boot" secuence where after a black screen i get extrange login request
(similar to linux xsreensaver) but always get failed password
validation.
I resolved the problem killing session with CTRL+ALT+DELETE.
What's happening ?
Thanks in advance.
This sounds like a problem with xscreensaver dying under Solaris 10.
To be more accurate, xscreensaver (typically)
doesn't die, it simply imposes its grab too late
(the cause for this is still unknown). As a
result utxlock gets confused and launches xlock in
a session that already has xscreensaver running.
What usually happens in this case is that you can
unlock xlock (although you might not see this) but
xscreensaver has lost focus (and keeps the screen
blank) so there's no way to get the password typed
into it and get it to unblank the screen. CR
6573728 was filed to create a workaround for this
problem in SRSS. The workaround is waiting to go
out in the next 3.1 patch release. I'm sorry you
had the perception that "not much progress" had
been made. You may have been referred to the
actual xscreensaver bug, rather than the SRSS
workaround for it (we decided not to wait for a
fix and instead change the way we deal with
xscreensaver to a more reliable interface, in
order to solve this problem for customers in as
timely a fashion as possible).
Until the patch is released, if this is a problem
for you it can be worked around temporarily by
turning off execute permission on the
xscreensaver-command program (this will mean
you'll use xlock to lock your sessions for the
time being). xlock should work fine if it's not
competing with xscreensaver for input focus.
# chmod a-x /usr/openwin/bin/xscreensaver-command
BTW, it is my experience that you *can* kill
xscreensaver when it is in this state, and in
fact that's the best way to regain access to your
session when this problem occurs. It is true that
the "ps" output shows "root" as the owner of the
process when it's in this state, but it's still killable
by the correct user (a way to figure out which
xscreensaver is yours is to run "ptree USER | grep xscreensaver"
for a particular user - even if ps shows "root"
ptree will report the correct pid). Hopefully you
haven't found yet another error case for our
nemesis xscreensaver.
I'm working on removing any reliance on screen
lockers in SRSS in future - this isn't the first
time they've caused problems for us and we want to
improve the product in this regard.
-Bob
As a
result of this xlock gets started and authentication does not work
any more.
You can try to find the xscreensaver process for your display and kill
it manually which will only leave the xlock process active. Then you can
unlock the screen with your password. A typical sign of this situation
is that the child process of the xscreensaver process is shown as
defunct
in the process table. One of the problems is that the xscreensaver can
only be killed as root if the screen is locked. We have a service call
open with Sun for this problem but so far there was not much progress.
I have sent quite a bit of debug output to Sun but the cause of the
problem has not yet been located. One of the problems in debugging this
xscreensaver problem is that it only appears intermittend and only for
some users. We have not yet found a correlation with any particular
settings.
There is a thread in the archives earlier this year where this problem
was discussed. One possibility to avoid the problem is to disable
xscreensaver
and only use xlock.
Regards,
Matthias
_______________________________________________
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
