Re: [SunRay-Users] Connection reset, reauthenticatingDuplicateTID
Hi Nicolas, First off, thanks for your kind help! El 23/09/2014 a las #4, Nicolas Schier escribió: Dear Nicolás, Recently we moved the Sun Ray clients to run against the production server, resulting in some of them running a graphic session without any faults, and some of them stucking in the '26D' screen. [...] I read that this could be due to the inability of renewing the DHCP lease, however, the SRS server is *not* configured as a DHCP server, we have a dedicated server for that. unfortunately I do not have a good idea what would might cause such logs. But I'm trying to ask some questions, hoping that one of them might be helpful in searching further... - Did you check that your DHCP server is still working as expected? Might some IPs be assigned non-exclusively? Yes, it is. I must emphasize that we don't use the Sun Ray's DHCP server (utadm), but a dedicated server for DHCP purposes and it's working fine all time. I don't think there might be an IP conflict, as the IP addresses for our clients are all bound by their MAC address. - Does the 'realIP' (0adb08e8=10.219.8.232 in your log example) stay the same or change according to your DHCP configuration? It's always the same for each client address, that's the weird thing. However, I've been looking for some extended information about this and I see people having this problem in the middle of users' session. In our case, it just happens when someone restarts the Sun-Ray client or logs out (as far as we have seen up to now). - If you trace the network traffic for a particular 26D-client: can you verify the connection loss as it is claimed by the server log? 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. Again, thanks for your help! Regards, Nicolás Good luck and kind regards, Nicolas ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
[SunRay-Users] OEL 6.5 + SRS 5.4.2 - Anybody running?
Hello, We are thinking about upgrading our current Oracle Linux 6.4 installation to Oracle Linux 6.5 with SunRay Software 5.4.2, is there anybody running it successfully? Any flaws we should care about? Thanks a lot signature.asc Description: OpenPGP digital signature ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
Re: [SunRay-Users] Connection reset, reauthenticatingDuplicateTID
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.00144fXX root 34 pseudo.00144fXX root 36 pseudo.00144fXX root 37 pseudo.00144fXX root 38 pseudo.00144fXX root 39 pseudo.00144fXX root 40 pseudo.00144fXX 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 SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
Re: [SunRay-Users] Connection reset, reauthenticatingDuplicateTID
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 nico...@devels.es 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.00144fXX root 34 pseudo.00144fXX root 36 pseudo.00144fXX root 37 pseudo.00144fXX root 38 pseudo.00144fXX root 39 pseudo.00144fXX root 40 pseudo.00144fXX 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 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
