Re Matthias questions:
> 1. Is it known why this happens and why sometimes xlock gets started
and can one prevent this.
The /opt/SUNWut/bin/utxlock script controls which screen lock is used so
I suggest you take a little time to look at it's content and understand
what happens when it's called on a smart card disconnect event.
Some possible reasons for xlock starting (assuming users are running
Gnome sessions) are:
The xscreensaver may not be running at all for some reason (e.g.
never launched or exited at some point) so when utxlock tries to
run the xscreensaver 'lock' command it fails. The utxlock
script then proceeds to try xlock.
Another possible reason is the users xscreensaver process may be
running but does not return success (i.e. "0") when asked to
'lock' so utxlock then proceeds to launch xlock. One
interesting thing I have noticed is the ownership of the users
xscreensaver process changes to root after a card is removed and
the screen saver is activated. When the card is re-inserted,
and the user is successfully authenticated, the ownership
changes back to the user. Not sure what's going on there? Any
Sun Ray Eng' folk care to comment on this one? Is it possible
this behaviour is contributing to unresponsive xscreensaver or
is this 'normal' (i.e. maybe something to do with session
disconnect and ownership of parent processes perhaps)?
> 2. Is there a way to make xlock unlockable in a sunray session?
Well, it's meant to be unlockable ...I find that keyboard input (e.g.
'shift' key) is usually reliable for getting xlock's attention. Mouse
input doesn't seem to work (probably by design). I have seen xlock
become totally unresponsive on occasion though.
> 3. Can one rescue such a session such that the user can at least save
their data?
Not that I've seen, especially when xlock wont play. I haven't tried
killing xlock to see what would happen although I suspect the user wont
get their session back.
Hope this helps...
Regards,
Peter
On Thu, 2007-01-25 at 09:44 +1100, Marcus Young wrote:
> Matthias,
>
> we have seen the same issue since the introduction of Solaris 10. Until
> recently it has occurred rarely (we are running something in the order of 600
> users on Sol10/Sparc) - possibly once or twice a month. However, last week
> we upgraded to the current patch level and the frequency has increased
> dramatically. In the majority of cases typing the password does not unlock
> the screen. We would now be experiencing at least 10-20 instances a day. We
> are seeing the "black" screen both on initial login and hot desking. The
> issue seems to arise regardless of loading. For example, when we initially
> configured the failover group a week or so ago - the first user logon went to
> the xlock screen.
>
> It is really starting to impact on users perception of SunRay technology -
> particularly since we use the devices to deliver time critical medical
> information. By the way, like you, we only use smartcards.
>
> We would be very interested to hear from anybody who has been able to
> identify the cause of the problem and define possible solutions.
>
> Marcus
>
>
> _______________________________________________
> 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
