We have having the exact same issue, luckily it's a single session that hangs (only a single root owned session in utwho -ac, and it's been :11. I have an open ticket with Oracle about this issue. Anyone found a way to clear those root owned sessions?
On Tue, Sep 23, 2014 at 1:15 PM, Nicolás <[email protected]> wrote: > El 23/09/2014 a las #4, Nicolás escribió: > >> That's something I've not tried yet and it's a good idea, I'll try to >> trace the traffic for that client and verify what kind of traffic is being >> sent between client and server. I've seen this is an issue that formerly >> appeared in 2010 but has not a clear diagnosis yet, and I don't know >> clearly how to force it for reproduction, but indeed once I do I'll try and >> post some updates. >> >> I've seen a similar issue on a blog which talks about some mess with the >> ARP table on the server side (http://www.planetgeek.ch/ >> 2012/04/02/sunray-terminal-unexpected-reboot/). I'll try to check the >> ARP table as well and see if it helps determining the problem. >> > > Today we've been "lucky" and had about 8-9 clients hung with this issue, > so I tried further tests and here are the conclussions: > > * Yesterday we had upgraded from 5.4.0 to 5.4.3, obviously this didn't fix > the issue. > * The ARP table issue has nothing to do with this. The ARP table is ok. > * Even using 'utsession -k -t', the hung client keeps sending KeepAlive > packets like these: > > keepAliveReq _=1 byteCount=0 connTime=5722.63 > fw=11.1.3.0_26_2013.10.28.09.53,Boot:MfgPkg_4.15_2006.07. > 20.16.57;\0402006.07.20-17:04:56-PDT hw=SunRayP8 idleTime=5308.54 > latency=869 lossCount=0 namespace=IEEE802 pktCount=0 pn=38837 > sn=00144f3c8156 state=connected. > > * We discovered we can have a list of hung clients via the 'utwho' > command, as these are marked as 'root' sessions. > > 33 pseudo.00144fXXXXXX root > 34 pseudo.00144fXXXXXX root > 36 pseudo.00144fXXXXXX root > 37 pseudo.00144fXXXXXX root > 38 pseudo.00144fXXXXXX root > 39 pseudo.00144fXXXXXX root > 40 pseudo.00144fXXXXXX root > > * What is even more worrying: Today I had an idle client just near me for > about 1 hour, it simply destroyed the GDM greeter and stucked at the 26D > screen, without any human action. > > * I guess an 'utsession -k -t' command would destroy the session, but > despite this the client would follow sending the above keepalive packets. I > don't know whether this could be fixed killing the corresponding GDM > process for a client? However, I don't know either how to know which gdm > process is attached to a user session, is that possible to know? > > Regards. > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users > -- Greg Rodenhiser Technical Services Engineer College of the Holy Cross
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
