The other way I've seen, even before a power cycle is via utsession -p. If the Unix session column is ??? but the state is U (as opposed to IU) it is the Sunray session(s) that are hung on 26B. At 4AM everyday I run utstop/utstart via cron, and check every morning for the hung session. In our case it's always just a single display out of the 35 we use.
On Fri, Oct 3, 2014 at 2:14 PM, James Michels < karma.sometimes.hu...@gmail.com> wrote: > Hello Greg, > > 2014-10-03 19:01 GMT+01:00 Rodenhiser, Greg <grode...@holycross.edu>: > >> I may have a way to auto detect a hung session (at least for our 26B >> hangs it works). Run a utwho -a. Any session that is owned by root is a >> hung session for us (provided root is not actually logged into any of our >> Sunray sessions). The fact that it's owned by root seems to block Xnewt >> from spinning up on that display, giving the dreaded 26B (and maybe D)? >> >> > This is the way we use, but it only works when the client has been already > power-cycled :-( After that, the utwho -ca command shows that MAC being > owned by root as you describe, but only after that fact. Until > power-cycling, it appears being an idle session. That's the reason why I > was tinkering with utquery and see its parameters, but they're the same as > for a "sane" session. Even packets being sent from that hung session seems > to be the same of a normal session, so its camouflage is brilliant :-) > > Thanks for the tip! > > James > > > >> On Fri, Oct 3, 2014 at 1:51 PM, James Michels < >> karma.sometimes.hu...@gmail.com> wrote: >> >>> Hello all, >>> >>> As promised, I'm posting some feedback about your idea. In conclusion, a >>> mix of both Scott's and Daniel's ideas has *almost*-worked for me. When >>> using just the utload & utsession commands, the thing didn't seem to work. >>> However, I tried adding/removing things and tracing their effects and the >>> conclusions are the following: >>> >>> - The command combination that seems to work for me is "utdesktop -d >>> XXXXXXXXXXXX" + "utload -r -t pseudo.XXXXXXXXXXXX" + "utsession -k -t >>> pseudo.XXXXXXXXXXXX". >>> - The strange thing is that run just once, the client still seems to >>> be hung after reboot. Only after running the same command 5-6 times, the >>> client seems to start correctly. That seems pretty strange to me, as the >>> three commands are run exactly the same way the 5-6 times. >>> - This combination implies Scott's solution, there's just one path >>> left: /tmp/SUNWut/kiosk/:DISPLAY..., so I made a script that additionally >>> removes that path and added it to the 3 commands above. >>> - As far as my pretension of detecting hung sessions without >>> restarting the client for the first time goes, it seems that it won't >>> work >>> the way I meant. The utquery command returns correct values on the >>> cmdcachesize parameter before rebooting, so this won't work. Now I'm >>> still >>> looking for a way to detect those hung clients without telling our >>> workers >>> to power cycle them manually. >>> >>> This has been a big help as at least I can reset the hung state of the >>> clients now and I don't need to wait for the nightly utstart -c, so thank >>> you Scott and Daniel. >>> >>> If someone has an idea on how to detect a hung client without needing to >>> power cycle them, I'll be very grateful. >>> >>> James >>> >>> >>> 2014-10-02 20:25 GMT+01:00 James Michels < >>> karma.sometimes.hu...@gmail.com>: >>> >>>> Hello Daniel, >>>> >>>> 2014-10-02 18:51 GMT+01:00 Beckman, Daniel <d...@loc.gov>: >>>> >>>>> This may be a different issue, but with SRS 5.3.1 on Solaris 10, when >>>>> we run “utdesktop –lw” we sometimes show units that can’t get a session >>>>> and >>>>> are “stuck”. I think they are 26Ds as well. >>>>> >>>>> >>>>> >>>>> On an individual DTU basis, to fix remotely we issue this: >>>>> >>>>> >>>>> >>>>> /opt/SUNWut/lib/utload -r -t pseudo.00144fd6d4c7 && utsession -k -t >>>>> pseudo.00144fd6d4c7 >>>>> >>>>> >>>>> >>>>> Where “pseudo.xxx..” is the identifier that shows up in output of >>>>> “utdesktop –lw”. >>>>> >>>>> >>>>> >>>> >>>> In our case the 26D seems to be a bit more complicated to detect (not >>>> sure if OL and Sun base might have different behaviors), but when a session >>>> gets hung, initially it's still recognized as a valid session and doesn't >>>> appear in the -lw list until someone power cycles the client. Then the 26D >>>> is shown again, but this time it appears in the -lw list. Our aim is to >>>> find out a way to discover those hung sessions in their 'initial' state, >>>> where the SRSS doesn't catalogue them as hung yet. >>>> >>>> I've a possible idea, but I have to test it quite lot yet. It's based >>>> on the output of the utquery command, concretly on the cmdcachesize >>>> parameter which seems to be 0 when the session is hung, but as I said, I'm >>>> not quite sure of this yet. >>>> >>>> I've tried using the 'utsession -k -t' command, but it doesn't seem to >>>> "unstick" the session itself, however, I've not tried in combination with >>>> the 'utload' command, so I'll also try that tomorrow and see its behavior. >>>> >>>> Thanks very much for that idea, too. >>>> >>>> James >>>> >>>> >>>>> What that will do is “unstick” (for lack of a better term) the session >>>>> associated with that DTU and then reboot it. >>>>> >>>>> >>>>> >>>>> To make things easier we have a simple script that asks for the >>>>> identifier: >>>>> >>>>> >>>>> >>>>> #!/usr/bin/bash >>>>> >>>>> read -p "Enter the Desktop ID: : " DesktopID >>>>> >>>>> /opt/SUNWut/lib/utload -r -t pseudo.$DesktopID && utsession -k -t >>>>> pseudo.$DesktopID >>>>> >>>>> >>>>> >>>>> To make things automated we have a script that runs via cron by the >>>>> hour: >>>>> >>>>> >>>>> >>>>> #!/usr/bin/bash >>>>> >>>>> # Set variable for "DesktopID" based on output of utdesktop -lw >>>>> >>>>> DesktopID=$(utdesktop -lw | awk 'NR>3 && NR<5 {print $1}' ) >>>>> >>>>> # Only continue if "utdesktop -lw" reports a hung session, indicated >>>>> by existence of ID starting with 00 >>>>> >>>>> if [[ "$DesktopID" == 00* ]] >>>>> >>>>> then >>>>> >>>>> echo "There's hung sessions -- fixing them..." >>>>> >>>>> /opt/SUNWut/lib/utload -r -t pseudo.$DesktopID && utsession -k -t >>>>> pseudo.$DesktopID >>>>> >>>>> else >>>>> >>>>> echo "No hung sessions -- we're done here!" >>>>> >>>>> fi >>>>> >>>>> >>>>> >>>>> I’m not a programmer so I apologize if the scripts are a bit crude – >>>>> but they work for us. >>>>> >>>>> >>>>> >>>>> Hope that helps! >>>>> >>>>> >>>>> >>>>> Best, >>>>> >>>>> Daniel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* James Michels [mailto:karma.sometimes.hu...@gmail.com] >>>>> *Sent:* Thursday, October 02, 2014 8:33 AM >>>>> *To:* sunray-users@filibeto.org >>>>> *Subject:* [SunRay-Users] 26D and ability to effectively erase >>>>> sessions >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> We're getting spotaneous and unpredictable 26D screens sometimes. This >>>>> doesn't happen quite often, but what's worrying is that we're unable to >>>>> restore the affected client's state to be reset. >>>>> >>>>> We've tried to reset the client using the utsession -k -t command, >>>>> also utdisplay -d and both of them seem uneffective, as when rebooted, the >>>>> client remains in the same 26D state. >>>>> >>>>> The only thing that helps is a complete server reboot. >>>>> >>>>> When the client reconnects to the server we're seeing this in the log >>>>> so maybe it's related: >>>>> >>>>> Oct 2 12:43:52 srss7 utauthd: search_for_entries(): Found multiple >>>>> matching entries, was expecting a single match >>>>> >>>>> >>>>> >>>>> I deduce that the session is not being cleaned up entirely, so here's >>>>> my question: >>>>> >>>>> >>>>> >>>>> Is there a *effective* way for completely wipe the information from a >>>>> client? Something like this must be possible, otherwise a complete server >>>>> restart wouldn't help either. >>>>> >>>>> >>>>> >>>>> I don't mind connecting to the local LDAP server and deleting >>>>> 'something' by hand, but I'd like to know a way. We're running OL6.5. >>>>> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >>>>> James >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> >> -- >> >> >> Greg Rodenhiser >> Technical Services Engineer >> College of the Holy Cross >> >> _______________________________________________ >> 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 > > -- Greg Rodenhiser Technical Services Engineer College of the Holy Cross
_______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users