On 01/13/11 19:57, Karl Rossing wrote:
Would the issue i'm seeing be CR# 6623505?
We can't know the answer to this without some of the information I requested. -Bob
If so, I'll have to figure out how to place an IDR. On 01/04/11, *Bob Doolittle *<bob.doolit...@oracle.com> wrote: > Well then there you go. The associated session is on Server 2, display 5. If > you just want to clean the situation up, you can try a couple of things: > > 1 Is there an Xnewt running for display :5 (the display number is visible on > the command line via ps)? I'll have to try that. > 2 If you reset the DTU, does the problem go away or persist? On kiosks sessions, it's hit or miss. On card sessions it usually persists. > 3 If the problem goes away when the DTU is reset, the DTU is in a bad state. > You can use "/opt/SUNWut/lib/utload -r -t TOKEN" (where TOKEN is reported by > utwho -ac) to reset the DTU remotely when the problem occurs Usually terminating the session using the gui doesn't fix the problem. > 4 If the problem persists when the DTU is reset, the session is somehow hung. > You can use "utsession -k -d 5" if you want to simply clear the session and > processes. I'll have to try that. > It would be good to track down that's causing this situation. Is Server 2 > starved for resources (e.g. VM or /tmp space), or has it been starved in the > recent past? Clues might be found in the logs (both /var/log/messages and > /var/opt/SUNWut/log/messages) around the time in question (when the current > time minus "No-Session" time occurred). I'll have to investigate this more. Sometimes /tmp can be a bit low and the server can be bogged down. I can try assigning more memory to the vm. > > -Bob > > On 01/04/11 11:59, Karl Rossing wrote: > >Server 1 > >-bash-4.0$ /opt/SUNWut/sbin/utdesktop -lw > > > >Desktop ID Location No-Session (H:M:S) > >------------ -------------------- ------------------ > >00144f7f456e 1:35:21 > > > >1 desktop currently in error state without a session. > >-bash-4.0$ /opt/SUNWut/bin/utwho -ac|grep 00144f7f456e > >-bash-4.0$ > > > >Server 2 > >-bash-4.0$ /opt/SUNWut/sbin/utdesktop -lw > > > >Desktop ID Location No-Session (H:M:S) > >------------ -------------------- ------------------ > >00144f7f456e 1:33:21 > > > >1 desktop currently in error state without a session. > >-bash-4.0$ /opt/SUNWut/bin/utwho -ac|grep 00144f7f456e > > 5.0 pseudo.00144f7f456e utku3 10.1.9.236 P8.00144f7f456e > > > >Server 3 > >-bash-4.0$ /opt/SUNWut/sbin/utdesktop -lw > > > >Desktop ID Location No-Session (H:M:S) > >------------ -------------------- ------------------ > >00144f7f456e 1:37:1 > > > >1 desktop currently in error state without a session. > >-bash-4.0$ /opt/SUNWut/bin/utwho -ac|grep 00144f7f456e > >-bash-4.0$ > > > >Karl > > > >On 11-01-04 10:42 AM, Bob Doolittle wrote: > >>Perhaps we can help. Can you answer my question please? Does "utwho -ac" on > any of the servers show the DTUs which are reported by "utdesktop -lw"? > >> > >>-Bob > >> > >>On 01/04/11 11:27, Karl Rossing wrote: > >>>What I'm trying to do is to proactively find dtu's that are showing 26d. > >>> > >>>I have 110 DTU's on 3 servers in a fog. 26d errors get worse over time. > >>> > >>>Karl > >>> > >>>On 11-01-04 10:04 AM, Bob Doolittle wrote: > >>>>On 01/04/11 10:43, Karl Rossing wrote: > >>>>> > >>>>>utdesktop -lw will show me desktops that are in an errored state. > >>>>> > >>>>>How can I find out a process id for the errored session? > >>>> > >>>>When you see DTUs in this state, do they show up anywhere with "utwho -c"? > If so, that should indicate the display number. You should be able to find the > associated processes from that. I imagine you'd only care about the Xnewt > server. This state can occur in some circumstances if the X server is hung or > has crashed. > >>>> > >>>>Your problem is going to be that if there is a large number of servers at > your site you will have to track down which server is hosting the session for > the DTU. > >>>> > >>>>-Bob > >>>> > >>> > >>> > >>> > >>>CONFIDENTIALITY NOTICE: This communication (including all attachments) is > >>>confidential and is intended for the use of the named addressee(s) only and > >>>may contain information that is private, confidential, privileged, and > >>>exempt from disclosure under law. All rights to privilege are expressly > >>>claimed and reserved and are not waived. Any use, dissemination, > >>>distribution, copying or disclosure of this message and any attachments, in > >>>whole or in part, by anyone other than the intended recipient(s) is strictly > >>>prohibited. If you have received this communication in error, please notify > >>>the sender immediately, delete this communication from all data storage > >>>devices and destroy all hard copies. > >> > > > > > > > >CONFIDENTIALITY NOTICE: This communication (including all attachments) is > >confidential and is intended for the use of the named addressee(s) only and > >may contain information that is private, confidential, privileged, and > >exempt from disclosure under law. All rights to privilege are expressly > >claimed and reserved and are not waived. Any use, dissemination, > >distribution, copying or disclosure of this message and any attachments, in > >whole or in part, by anyone other than the intended recipient(s) is strictly > >prohibited. If you have received this communication in error, please notify > >the sender immediately, delete this communication from all data storage > >devices and destroy all hard copies. > -- Karl Rossing The Robinson Group System Administrator _______________________________________________ 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
