Bob Doolittle wrote:
> 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.
We have all the latest patches for xscreensaver. I did not realize that utxlock
was a shell script. I will have a closer look at it.
>
>>> 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.
Which PID should I use to run the pstack on? The xlock was killed
and did not run anymore. But the session was unresponsive and blank.
>
> 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.
We have all the latest patches as of early January. I killed the xlock process
and I made sure it was killed afterwards, I killed the utxlock process and both
did not help the session was still blank.
Since this happened, I took more drastic measures. I moved xlock to a different
name in the hope that the blank screen problem would go away. But it did not.
I just had a user who did not have access to his session anymore. The screen was
blank and there was no xlock running. But I found a xscreensaver running as root
on the display of the user with a defunct child process owned by the user:
root 8881 1 0 Jan 15 pts/66 0:42 xscreensaver -nosplash
towe 22942 8881 0 - ? 0:01 <defunct>
After killing this root-owned xscreensaver process the Sunray session was
accessible but would no longer lock on removing the card. Th utxlock process
is still running.
I now suspect that after killing the xlock in the earlier cases, maybe there
was also such a xscreensaver instance still around that made the screen stay
blank.
This is really becoming a problem for us.
Regards,
Matthias Ernst
--
+----------------------------------------+-----------------------------------+
| Matthias Ernst | Phone: +41-44-632-4366 |
| ETH Zürich, HCI D 227 | Fax: +41-44-632-1621 |
| Laboratorium für Physikalische Chemie | |
| Wolfgang-Pauli-Strasse 10 | Email: [EMAIL PROTECTED] |
| CH-8093 Zürich, Switzerland | [EMAIL PROTECTED] |
+----------------------------------------+-----------------------------------+
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
