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”.
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:[email protected]]
Sent: Thursday, October 02, 2014 8:33 AM
To: [email protected]
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
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
