Matthias Ernst wrote:
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 certainly sounding like an xscreensaver problem. Perhaps you can disable xscreensaver entirely, and rely on xlock? It sounds to me like xlock was *not* your problem, and may well have been functioning correctly. If you have a service contract, I'd recommend filing an escalation against xscreensaver. There's a new patch in the works for it that may address your problem, and you might be able to get binary relief. The simple test is to try to run xscreensaver-cmd to cause the xscreensaver command to lock the screen (you can look at utxlock to see how to do this). If it's not responding, that's your culprit. If you're going to contact service, then taking a pstack of xscreensaver when it is in this state might help identify the problem to the xscreensaver team, and determine whether the forthcoming patch addresses your problem or not. -Bob _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
