If so, I'll have to figure out how to place an IDR.
On 01/04/11, Bob Doolittle <bob.doolit...@oracle.com> wrote:
I'll have to try that.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)?
On kiosks sessions, it's hit or miss. On card sessions it usually persists.2 If you reset the DTU, does the problem go away or persist?
Usually terminating the session using the gui doesn't fix the problem.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
I'll have to try that.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 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.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).
-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
