26B means that communications between the client and the X server (or YUV client) has been interrupted.
Typical causes are: - network failure - X server crashed, and wasn't properly restarted - X server hung - it's a YUV session (used to display error or state-indicating icons without an X server) and the YUV client (yuvfile) isn't rendering to the screen properly or has died undetected So the first step is to test whether you can ping the DTU from the server. If you can, you need to investigate the X server. I wouldn't suspect that PAM could cause the X server to become horribly hung, although theoretically anything could tickle a bug resulting in an X server crash. Seems unlikely to me. It appears you're on Solaris. Is it Solaris 10 or OpenSolaris? What version and patch rev of SRSS? I'd first of all try to identify the session that the client is supposedly servicing. utwho -ca should help there. What type of session is it? Is it a greeter, RHA (session locked), YUV (error icon of some sort), or logged-in session? You can look in /var/opt/SUNWut/displays/DISPLAYNUM at the SESSION_TYPE. If it's "default" then the Display Manager (dtlogin for S10, GDM for OpenSolaris/S11/Linux) is responsible to restart the server if it dies. Otherwise it's SRSS's responsibility. Then I'd look for the Xnewt process servicing that display. Is there one? If so, I'd try a pstack and also look in the Xserver error log for clues: S10: /var/dt/Xerrors S11 (or Linux): /var/log/gdm/:DISPLAYNUM Sometimes we've observed that 26 can occur when /tmp gets clobbered and the /tmp/SUNWut directory structure has been disturbed, or the host has run out of VM/swap space at some point and couldn't write to /tmp/SUNWut when it needed to. We do a lot of book-keeping in that area and if it's corrupted the software can misbehave. Check /var/adm/messages for signs of VM starvation. -Bob On 01/11/11 13:30, Devin Nate wrote:
Dear SunRay users (hopefully Bob, Craig also?); We're continuing to have problems with random 26B's, and don't even know where to begin to help debug. We don't see any particular errors in log files, besides several pam messages. The 26B's are happening on new sun ray 3's and older sun ray 2's. So far, our only theory is a PAM problem ... we appear to have many of the following style messages. dtlogin[990]: [ID 691260 user.notice] pam_sunray_hotdesk:pam_sm_auth: ut_getTokenByDisplay failed -1 for display :51 We run fully stock PAM, no customizations. In any event, does anyone have any theories as to how to debug 26B's? In the most recent case, card removal corrected (went back to solaris login screen), and card insert worked exactly as expected and 26B was gone. Please, any ideas on trouble shooting? We don't even really know what likely candidates for a 26B are to start a process. Thanks, Devin From: sunray-users-boun...@filibeto.org [mailto:sunray-users-boun...@filibeto.org] On Behalf Of Devin Nate Sent: Tuesday, January 04, 2011 6:00 PM To: 'sunray-users@filibeto.org' Subject: [SunRay-Users] Sun Ray 26B - several models - SRS 5.1.1 Hi Folks; We recently applied some sun ray patches, and are now experiencing some new problems. In particular, the following updates: 1. Applied all patches from smpatch for Solaris 10, x86-64. Approx 300 patches were applied. a. Performed prescribed reboots, single user patching, and configuration reboots. 2. Applied Java SDK 1.6.0_23, and activated as default java instance. Previously, we were at 1.5 (for some unknown reason). 3. Applied SRS 5.1.1. We were previously at patch level -03 (now -06 it seems), as well as SRWC 2.3 (previously 2.2). The new undesirable behavior we are seeing: 1. Our users all use a Kiosk app to access windows terminal servers using uttsc. Intermittently, with card inserted and the kiosk app running (i.e. uttsc), the sun ray will display a 26B dialog box floating around for no apparent reason. The user is still able to fully use the system, just the annoyance of the 26B window floating around. a. Our policy requires full encryption + client authentication. These dtu's are all authenticated and have worked continuously for a long time without this symptom. b. A stop-A tends to be able to make it go away. It ?sometimes? comes back after ?some? unknown period of time, and doesn't impact all users. c. Removal of the card properly takes the user back to the standard login solaris login screen. Re-insertion of the card back to the terminal server session. d. Seen on SunRay 2 DTU and new SunRay 3. 2. Possibly related: When in the srs management website, after first patching (and still viewable), sessions show as disconnected that are clearly connected. In the most extreme case, I was in a OVDC session logged into a kiosk session (into a terminal server). I was on that terminal server looking at the srs website, at my session, which was identified as 'disconnected'. Further investigation showed that on initial login, the session shows as connected for a few minutes, after which it goes to disconnected, even though nothing becomes disconnected (i.e. still using the session). Likewise, reconnection works just fine. Any feedback helpful, thanks, Devin _______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
