[SunRay-Users] xlock screen locking -

[Bob Doolittle]

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