Hi there,
I've implemented the following script that seems to work nicely for us.
We've however seen some cases where the client is hung and it reports being
IDLE in the utsession -p output, so this will probably also require some
script to restart idle sessions from time to time (say once every 2 hours),
so after cycling it should report the correct value. Odd, though.
Again, thanks for your help!
#!/bin/bash
# Paths to commands
LOGGER=`which logger`
UTSESSIONCMD=/opt/SUNWut/sbin/utsession
UTDESKTOPCMD=/opt/SUNWut/sbin/utdesktop
UTLOADCMD=/opt/SUNWut/lib/utload
IFS=$'\n'
# The following loop will return any sessions in the SID, Login, Status
format
for dtu in `$UTSESSIONCMD -p | tr -s ' ' | cut -d' ' -f1,3,5`; do
# The first returned row is empty, we discard it
[ -z "$dtu" ] && continue
# Acquiring needed values for each row
sid=`echo $dtu | cut -d' ' -f1`
login=`echo $dtu | cut -d' ' -f2`
state=`echo $dtu | cut -d' ' -f3`
# The utsession doesn't seem to be meant to be formatted for scripting,
there will be
# some rows that will return useless info.
[ $sid == "Token" ] && continue
[[ $sid =~ ----* ]] && continue
# If the DTU haven't an associated login and neither has the IDLE flag,
probably is hung
# We restart it!
if [ $login == '???' ] && ! [[ $state == I* ]]; then
$UTDESKTOPCMD -d `echo $sid | cut -d'.' -f2`
$UTLOADCMD -r -t $sid
$UTSESSIONCMD -k -t $sid
$LOGGER -t hung_session Restarting $sid as it seems to be hung
echo "DTU $sid has been restarted"
fi
done
exit 0
2014-10-03 19:42 GMT+01:00 James Michels <karma.sometimes.hu...@gmail.com>:
> Greg,
>
> 2014-10-03 19:32 GMT+01:00 Rodenhiser, Greg <grode...@holycross.edu>:
>
>> 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.
>>
>>
> This seems very promising! I'll check on monday and post some feedback
> about it, respectively the script I've implemented to kill hung sessions.
>
> Thank you all, your tips will most probably solve my issue.
>
> Happy weekend,
>
> James
>
>
>> 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
>>
>>
>
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
