> Hubert, Matthias wrote: > > Hi! > > > > In reply to this post from February: > > > > > >> Anyone run into the following: thin client user is in the middle of > >> working in Windows. All of a sudden, the white mouse cursor turns into > >> a black "X" and the user loses mouse control [although, in my limited > >> experience, he still has keyboard control]. Doing a "CTL moon" helps > >> but only briefly: anywhere from a few seconds to a few minutes later, > >> the problem returns. > >> > >> Dave Partington has seen this at his site but his fix had to do with > >> altering the location where the mouse plugs in and this doesn't work > >> > > for > > > >> me. We solved it by moving the user's session off of the SRS [all of > >> the "bad" TCs were on the same SRS but most TCs on that SRS were not > >> experiencing the problem] to another one [we have 3 in the FoG]. > >> > >> We're using SRSS 4.0 on Solaris 10 [Sparc] but have not yet applied the > >> Windows connector patch [127556-01]. After we rebooted the problem has > >> not returned and we can't reproduce it either. > >> > >> We got a lot of errors in /var/opt/SUNWut/log/messages: > >> > >> Jan 31 05:34:05 rsunsu01 utxconfig[18012]: [ID 702911 user.info] Error: > >> could not open file '/var/opt/SUNWut/displays/11' for reading. > >> > >> These errors were happening while the users were having the problems > >> > > but > > > >> persisted after the problem went away [with the switch of SRS] so I > >> think it was coincidence. The display # didn't exist in the "utwho > >> > > -ca" > > > >> output so we couldn't trace it to an actual TC. > >> > >> Thanks in advance. > >> > >> Scott > >> > > > > > > We have a similar problem to this. But this not only happen to Windows > > as well as working in terminal. > > Mouse pointer turns into black X and after a while the SunRay OSD shows > > a window complaining that there is no network available, although > > keyboard is working fine. After pressing ESC you can work for approx. 10 > > min, before problems starting again. The only workaround I could find, > > was changing the smart card to a new one and creating a new session. But > > this only lasts for a few weeks, after the problem starts again. It is > > not related to the DTU, because the problem is connected to the session > > as you can move with it to another DTU. > > > > Would be very nice, if someone could help me. > > > > Matthais, it seems unlikely that you would need to use a new smart card. > > Have you tried simply terminating the original session (either > Ctrl-Alt-Bksp-Bksp or else utsession -k from another login) and creating > a new one with the same smart card? Of course that's not a solution, > but it would help isolate the problem. > > What OS are you using? Is it relatively up-to-date with patches? If > Linux, are you using the version of Java supplied with SRSS in the > Supplemental area? It sounds like a problem either in the OS itself or > utauthd/java. Is only one session affected, or are all sessions on that > server affected at the same time? > > -Bob > Hi Bob. We are using SRSS4.0-48 on CentOS4. The CentOS is up2date with patches. Only the SRSS is missing the latest Patch. Only a few sessions are affected, but not all on that server. The OSD shows a 26D error. Creating a new session would help for some days. utauthd is using java in /etc/opt/SUNWut/jre/bin/java, which is version 1.5.0_11-b03 Thanks for your help Matthias
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
