Hello Scott, 2014-10-02 15:28 GMT+01:00 Nishimura, Scott L (ESS) <scott.nishim...@ngc.com >:
> I ran into this problem in an older version of SRSS and found the only > solution, short of a server reboot, was to go into /tmp/SUNWut and delete > everything that had that thin client's MAC. There were about 6 files to > delete and also an entry in another file [which cautioned in the header "do > not edit", which I ignored : ) ]. > > Do you (by chance) remember if the "DO NOT EDIT" file was also under the /tmp/SUNWut directory? As far I've been able to find those files: config/dispinfo/27:TERMINAL_ID=IEEE802.00XXXXXXXXXX config/ctokens/pseudo.00XXXXXXXXXX:TOKEN=pseudo.00XXXXXXXXXX config/ctokens/pseudo.00XXXXXXXXXX:TOKEN_SET=pseudo.00XXXXXXXXXX config/ctokens/pseudo.00XXXXXXXXXX:INSERT_TOKEN=pseudo.00XXXXXXXXXX config/displays/27:TOKEN=pseudo.00XXXXXXXXXX config/displays/27:TOKEN_SET=pseudo.00XXXXXXXXXX config/displays/27:INSERT_TOKEN=pseudo.00XXXXXXXXXX config/itokens/pseudo.00XXXXXXXXXX:TOKEN=pseudo.00XXXXXXXXXX config/itokens/pseudo.00XXXXXXXXXX:TOKEN_SET=pseudo.00XXXXXXXXXX config/itokens/pseudo.00XXXXXXXXXX:INSERT_TOKEN=pseudo.00XXXXXXXXXX config/xconfig/Xconfig:DisplayManager.*_27.environment: SUN_SUNRAY_TOKEN=pseudo.00XXXXXXXXXX CORONA_TOKEN=pseudo.00XXXXXXXXXX But none of them contains such warning. Anyways, this is much more then I had up until now, so I'll test it tomorrow and provide some feedback. Thank you very much! > I don't remember if I had to do that on all FOG members; I don't think so. > > YMMV > Use at your own risk > etc > > Regards, James > > From: sunray-users-boun...@filibeto.org [mailto: > sunray-users-boun...@filibeto.org] On Behalf Of James Michels > Sent: Thursday, October 02, 2014 5:33 AM > To: sunray-users@filibeto.org > Subject: EXT :[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
