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
