Peter Anderson wrote:
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)?
There have been a lot of bugs with xscreensaver. Sometimes it hangs and
won't respond to a lock request, in which case utxlock will attempt to use
xlock as a fallback. Make sure you have up-to-date patches for
xscreensaver.
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.
I suspect they will. xlock is a simple X
application that just happens to blank the screen
and grab server focus. If you kill it off, the
window should disappear and the grab should be
released, unless the X server itself is broken
somehow.
I'm suspecting some sort of user error (no
offense) when you tried to kill xlock off, because
nothing should prevent this. If you're sure you
did this as root and got the PID right, run pstack
on the PID and send us the output.
It's mysterious why xlock won't accept a password,
however. Check /etc/pam.conf and make sure it
doesn't have a strange PAM auth stack. Make sure
you have up-to-date X patches.
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
